Understanding Spectre and Meltdown – Part 2(miuv.blog)
miuv.blog
Understanding Spectre and Meltdown – Part 2
https://miuv.blog/2018/03/20/understanding-spectre-and-meltdown-vulnerability-part-2/
3 comments
You don’t really need a cache flush - you just blow out the caches manually. Which is conveniently straight line code that modern jits are really good at optimizing :)
No the fix for meltdown is to essentially force a tlb flush (as Linux is doing).
Note that only resolves is reading kernel memory, it doesn’t resolve Spectre. That basically requires browsers to be super sure about their bounds checking logic.
I don’t know what other engines did, but in JSC all indexing operations are now essentially:
If (idx < length) return data[idx & mask]
Where each indexable object stores a length mask that is essentially the next power of two up from the length.
It takes up space on every object (a word for the mask) reuquired removing butterflies and had a significant perf impact :-/
I’m 100% sure @pizlonator will say I have completely bollocksed up this description :)
No the fix for meltdown is to essentially force a tlb flush (as Linux is doing).
Note that only resolves is reading kernel memory, it doesn’t resolve Spectre. That basically requires browsers to be super sure about their bounds checking logic.
I don’t know what other engines did, but in JSC all indexing operations are now essentially:
If (idx < length) return data[idx & mask]
Where each indexable object stores a length mask that is essentially the next power of two up from the length.
It takes up space on every object (a word for the mask) reuquired removing butterflies and had a significant perf impact :-/
I’m 100% sure @pizlonator will say I have completely bollocksed up this description :)
In most of the articles which i read or have have linked in the blog, most of them were about KPTI being the mitigation for the meltdown fix.
Actually now, with context switch to kernel mode, we now have to load the page table entries ( process + kernel ) which will essentially mean flushing of the TLB. But this is a side effect of the mitigation and not the main mitigation.
https://lwn.net/Articles/741878/
Actually now, with context switch to kernel mode, we now have to load the page table entries ( process + kernel ) which will essentially mean flushing of the TLB. But this is a side effect of the mitigation and not the main mitigation.
https://lwn.net/Articles/741878/
I'm not sure exceptions are only checked on retiring the instructions. I thought they were checked earlier on. They can be checked even earlier since the page table has the access information and can fail very early (this makes the meltdown fix easy from a hardware perspective and could possible free up resources on chip earlier on an interrupted computation).