71–80 of 232 posts
I've been wondering (and haven't seen it addressed anywhere) if these attacks could be used to get the private key out of game consoles. These days I would assume not - that the key would be in a secure enclave - but the current generation of consoles are a few years old now and maybe that's not the case.
Earlier quoted context omitted.
> This one is limited to 5 to 20 us resolution to prevent such attacks. * make such attacks more difficult.
Impossible. This attack relies on detecting the timing between a cache hit and miss. If your clock resolution is larger than a cache miss then you can't differentiate the two events and so no information is leaked.
I understood everything up until the "suppose we flush our cache before executing the code" part which is probably the most important part. There was a comment below the article that explained this part a little further: > Imagine the value at the kernel address, which gets loaded into _w, was 0xabde3167. Then the value of _x is 0x100, and address user_mem[0x100] will end up in the cache. A subsequent load of user_me…
Yes, that is the this is left as an exercise for the reader part of the explanation. (-: The remaining part is to iterate the process over all of the bits in the word, using different bitmasks. The resultant set of 0 or 1 results for each bit yields the complete word. Then one iterates that whole process over all (useful) words in (mapped) kernel memory.
> In the good old days*, the speed of processors was well matched with the speed of memory access...Over the ensuing 35 years, processors have become very much faster, but memory only modestly so: a single Cortex-A53 in a Raspberry Pi 3 can execute an instruction roughly every 0.5ns (nanoseconds), but can take up to 100ns to access main memory. In real-world terms, what's the fastest processor we could build today wh…
Earlier quoted context omitted.
This covers both Meltdown and Spectre. > Both vulnerabilities exploit performance features (caching and speculative execution) common to many modern processors to leak data via a so-called side-channel attack. Happily, the Raspberry Pi isn’t susceptible to these vulnerabilities, because of the particular ARM cores that we use. The reason why Spectre is not a problem is because there is no branch predictor in these si…
There is almost certainly a branch predictor even in these simple ARM cores.
rpi 1: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/dd...
rpi 2: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DD...
rpi 3: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500d/DD...
As others have indicated further down, though, it won't open up much of a vulnerability unless they are speculatively fetching memory.
Ok I think I understand the subtleties of these attacks now. But: can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? If that happened then none of these attacks would be possible. I got my computer engineering degree in 1999 and ended up going the computer science route making CRUD apps all day. I feel in my gut that some engineer, somewhere,…
None of the RISC-V chips are either: https://riscv.org/2018/01/more-secure-world-risc-v-isa/
There's also this... https://groups.google.com/a/groups.riscv.org/forum/#!topic/i...
Earlier quoted context omitted.
There is almost certainly a branch predictor even in these simple ARM cores.
There's no reason to predict a branch if you're not going to execute speculatively. I need to re-read the papers but I think the real problem isn't even speculative execution but allowing speculative cache changes. The notion that "gadgets" didn't even need to return properly was both amusing and eye opening for me. It doesn't matter because the result will be flushed anyway! ;-)
In practice, advanced in-order designs contain more local reordering mechanisms, e.g. in the load/store unit, but they lack the unified global abstraction of a reorder buffer. The most successful timing attacks involve a mis-speculated load, so they wouldn't apply to these mechanisms, but it's not completely out of the question that they are also an effective side-channel.
Ok I think I understand the subtleties of these attacks now. But: can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? If that happened then none of these attacks would be possible. I got my computer engineering degree in 1999 and ended up going the computer science route making CRUD apps all day. I feel in my gut that some engineer, somewhere,…
There is no memory protection violation because it happens in the kernel; obviously, the kernel can read its own memory.