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.
Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
61–70 of 232 posts
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#62I've done some cursory searching and not found anything, so I'll ask here: what mechanism is used to measure how long it takes to access a specific address in memory? I assume there is some way to tell the CPU "when memory location X is read, store the current time in register Y" or some such thing. Could anyone share what that mechanism is?
Elsewhere in the thread, someone asked the same question and got an answer: https://news.ycombinator.com/item?id=16080230
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#63Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#64Technical details aside, I find it quite amusing that the hardware in my pi zero is more secure than my desktop that is two orders of magnitude more expensive
It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747, even if it is factually correct. I didn't downvote you (can't even do it), but I suspect you are getting downvoted because your analogy is so off the mark that it can't even be called "Apples vs Oranges". edit: replying to the "why the downvotes" which has since been edited away
> It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747
Actually, if it's true that a car gets a better mileage than a big airplane (more in one vehicle = more efficient, people seem to believe) I would find that interesting. Similarly, I can see how OP thinks it's ironic that a very cheap machine is not vulnerable whereas a quite expensive piece of equipment is, making it seemingly less-well engineered.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#65The cores in (all versions of?) Raspberry Pi do speculatively execute. It's just that the window of opportunity is tiny - just a few cycles (and maybe up to twice that many instructions) - and there's (probably) no way to get an indirected side-effect. I wouldn't write off the ability to get a useful side-effect signal. The variants widely documented are not the only possible methods of inducing speculative side-effe…
Yes, the Raspberry Pi will issue loads before the branch resolves. But usually a processor's pipeline won't be laid out in such a way that the AGU won't have time to pass an address to the load pipe before the branch resolves and squashes the load. The Cortex A8 was an interesting exception but it was pretty deeply pipelined compared to most in order cores.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#66Earlier 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! ;-)
> There's no reason to predict a branch if you're not going to execute speculatively.
Not quite. Branch prediction is typically used on non-speculative architectures in order to avoid pipeline bubbles. (You could argue that pipelining is a form of speculation)
Here is the branch prediction documentation for one of the processors they claim is not vulnerable. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
Whether or not they're vulnerable has more to do with how their pipeline is structured. It's possible for an architecture to be vulnerable if a request to the load store unit can be done within the window between post-branch instruction fetch/exec and a branch resolution. Eyeballing the pipeline diagram from the above docs, it looks like you can maybe get a request to the LSU off before the branch resolves. dramatic music
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#67Ok 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, MUST have asked this question at one of the big chip manufacturers.
Am I missing something fundamental? Is the access check too expensive? If it isn't, then can the microcode be updated to do this, or is caching/accessibility checking happening at a level above microcode? If that's the case then it would seem that pretty much all processors everywhere that do speculation without protected memory access checks are now obsolete.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#68I 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…
[deleted]
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#69Earlier 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.
Not quite. An instruction that takes 1us is much less likely to start and end in a different 20us clock cycle than a 10us instruction. Simple repeated sampling combined with statistics still yields a timing attack. It'll be slower and less deterministic, but it's still a problem.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#70Earlier quoted context omitted.
agreed
Me too. Finally I understand how the leakage works: no actual reading of kernel memory is taking place. Instead, the read-ahead/speculative logic causes one of two addresses in user space to be read, and thus placed in the cache. So, by reading both of them, and checking the time it took, the exploit can indirectly determine one bit (0 or 1) of kernel memory. Scary!
What are the exploits enabled by this? Seems like mostly security-related attacks on encryption keys and such.