Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

raspberrypi.org

Post reply on HN
Print view View original

91–100 of 232 posts

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#91

Post by AnsemWise »

zackmorris wrote: post #67

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,…

I hope I understand your question correctly. The request asks for something in protected memory and also asks for something based off a portion of the protected memory (like the first byte). The system denies access to the request then puts both results in cache. The attacker then asks for a byte of memory similar to the second request, which the system tries to get from cache but then goes to memory since it wasn't in cache. The attacker doesn't want that result so cancels the request and asks for another byte similar to the second request. That process repeats until the system says "Hey this byte is in my cache" and gives the result back to the attacker. That let's the attacker know what the first byte of that protected memory was. The attacker then repeats that whole process until they've read the entire protected memory, which is at a rate of 1500/bytes a second. It never gets the actual protected memory from the cache.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#93

Post by msbarnett »

zackmorris wrote: post #67

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,…

> 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.

If that happened, Meltdown wouldn't be possible on the processors on which it is possible.

Those checks in no way mitigate against Spectre. Spectre is both simpler and in many ways more profoundly devastating -- as long as an attacker can influence the statistics that the CPU uses for branch prediction, the very act of trying to "work ahead" in another process can be influenced by the attacker, and will produce some side-effects even if you throw out the result, and those side-effects suffice to infer information about the work you did but threw out.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#94

Post by ProblemFactory »

drb91 wrote: post #81
userbinator wrote: post #77

Earlier quoted context omitted.

The memory access could potentially take a very long time, so it makes sense to start it as early as possible, in parallel with all the other operations. Saving a few cycles on each memory access adds up significantly overall.

Right, but at a cost of a leaky cache abstraction. Which is now hugely expensive to work around, making me question how that ever got approved if the security model was clearly leaking at that point (which has been known for the entirety of speculative execution, right?)

> how that ever got approved if the security model was clearly leaking

When you consider a theoretical model of the CPU, then it's not leaking - the speculative execution, cache, other parts of the CPU are designed carefully so that no data can "escape" and be read by processes that don't have the permission to do it. Speculated execution can happen, but before any results from that are released, the permissions are checked, and if they fail, the results are discarded.

What people did not consider is the timing attacks that do leak information. It's only "clear" to us now after the attack has been demonstrated, even if it has been present in CPU design for the last 20 years.

There are probably many more of these side channel data extraction paths possible. For example, in the recent years attacks on cryptographic algorithms have looked at similar timing measurements, and in some cases power consumption measurements.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#96

Post by ufo »

rofex wrote: post #73
JdeBP wrote: post #37

Earlier quoted context omitted.

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.

Thanks, this was the missing piece in my understanding. I was wondering how only knowing only 1 bit would be useful. Suppose the attacker wants to read this entire address (0xabde3167) using this method. Is it guaranteed that over multiple runs, this address would be the same each time at that point in execution?

It is certainly possible that the memory the exploit is trying to read might be changing under its nose. An actual implementation of the exploit would need to account for that.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#97

Post by kwillets »

blattimwind wrote: post #15
Fronzie wrote: post #11

Earlier quoted context omitted.

in order to exploit it from a script running in a web-browser: there's a high-resolution timer in javascript. This one is limited to 5 to 20 us resolution to prevent such attacks. Recently a shared-memory extension has been proposed. one javascript thread just increments a counter in the shared memory, functioning as a clock for the other thread. In both cases, (Spectre) attacks can be prevented by browser updates, s…

> This one is limited to 5 to 20 us resolution to prevent such attacks. * make such attacks more difficult.

I've been pondering how to identify the cached line without a timer. It seems like a classical race condition if multiple reads can be issued at once, eg by ILP. Another thread could easily figure out which load completes first.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#98

Post by bazizbaziz »

Scaevolus wrote: post #49
blattimwind wrote: post #12

> The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort. I didn't check, but these will almost certainly have branch prediction. What they probably lack is a predictor advanced enough to speculate on indirect branches, which AIUI is the primary vector of Spectre.

Branch prediction alone is insufficient. Speculative execution alone is insufficient. You need speculative memory loads for any of these attacks to work. The Cortex-A53 branch predictor [1] does prefetching to keep the core fed. This ensures that the instructions are ready for decoding, but has no architectural effects beyond the L1 instruction cache, which is already a well-studied timing sidechannel. [1]: http://in…

What about the fact that these instructions might get partially executed in the pipeline before the branch gets resolved and the pipeline flushed? If a mis-fetched instruction can reach the LSU stage before the pipeline gets flushed, it might serve as a speculative memory load...

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#99

Post by msbarnett »

Spivak wrote: post #60
blattimwind wrote: post #15

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.

Right, but all this does is close off one possible avenue for a clever attacker to cobble together an HRT. Given the sheer number of JS APIs that have been thrown into browsers, I think it's pretty naive to imagine that we've closed off the only possible avenue to jury-rig a sufficiently precise measure of time.
Post reply on HN