4 ms·

Understanding Spectre and Meltdown – Part 2

43 points by mridulv09 9y ago

jnordwick 9y ago
The problem with JavaScript doing meltdown is that there is no easy way to flush the cache except by hand, and that is incredibly slow, especially if you need to flush from LL cache too. And you can't easily access a direct memory address. More than likely, the JIT machinery will get in the way. There just isn't an easy way to exploit meltdown in JavaScript lacking the direct memory poking or cache management. Has anybody seen a JavaScript exploit of meltdown? I still haven't, but I also got tired of looking a month ago. 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).
- olliej 9y ago
  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 :)
  - mridulv09 9y ago
    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/ https://lwn.net/Articles/741878/

43 points by mridulv09 9y ago

The problem with JavaScript doing meltdown is that there is no easy way to flush the cache except by hand, and that is incredibly slow, especially if you need to flush from LL cache too. And you can't easily access a direct memory address. More than likely, the JIT machinery will get in the way. There just isn't an easy way to exploit meltdown in JavaScript lacking the direct memory poking or cache management. Has anybody seen a JavaScript exploit of meltdown? I still haven't, but I also got tired of looking a month ago. 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).

olliej 9y ago
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 :)
- mridulv09 9y ago
  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/ https://lwn.net/Articles/741878/