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

81–90 of 232 posts

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

#81

Post by drb91 »

userbinator wrote: post #77
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,…

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?)

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

#82

Post by lelandbatey »

lucb1e wrote: post #62
lelandbatey wrote: post #39

I'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

Thank you for that link! I'll write out the conclusion I came too from reading those comments:

Instead of measuring the literal time interval between instructions, the number of cycles between two points is measured (using the RDTSCP instruction).

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

#83

Post by quasse »

piinbinary wrote: post #48
loeg wrote: post #42

Earlier quoted context omitted.

There is almost certainly a branch predictor even in these simple ARM cores.

(Asking for my own edification) What does the output of branch predictor get used for in a CPU without speculation?

Avoiding having to empty the instruction pipeline when a branch happens and restart. My favorite simple video explaining pipeline is still this old Apple one from back in the early 2000s:

https://youtu.be/PKF9GOE2q38?t=237

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

#84

Post by cwzwarich »

piinbinary wrote: post #48
loeg wrote: post #42

Earlier quoted context omitted.

There is almost certainly a branch predictor even in these simple ARM cores.

(Asking for my own edification) What does the output of branch predictor get used for in a CPU without speculation?

It is used to determine which instructions to fetch and decode, so that you don't have to wait until the branch is resolved to query the instruction cache, instruction TLB, MMU, DRAM, etc. If the branch was mispredicted, you have to stall to wait for this to complete.

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

#85

Post by infinite8s »

njitbew wrote: post #59

I enjoyed reading this a lot. I wonder why the developers decided to allow reading kernel-memory in the first place. When a scalar processor reads kernel memory, it crashes. When a speculative processor reads kernel memory, it relies on the assumption that the read is never committed to prevent leakage. It takes no expert to realise this is a potentially dangerous decision (and, as becomes clear now, is only valid in…

This is the part I don't understand. How is the processor able to read a cacheline from a protected memory page without crashing (even if it was speculative and wouldn't happen in the idealized execution due to branching).

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

#86

Post by ProblemFactory »

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

> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM?

From what I understand, it does happen on AMD, which is why AMD CPUs are not vulnerable to the more dangerous Meltdown attack (any code reading kernel / hypervisor host memory).

Intel / ARM delays the checks until later, to the time when the speculated instructions are actually finalised and make their results available. This is faster, and loading some memory into the cache is normally invisible to the unprivileged code. The checks would still be done when actually reading that memory. But nobody spent enough time considering the timing side-effects of the cache.

Now even if the protected memory reads are fixed by the OS updates - then it still leaves the Spectre attack - code running in a process reading all of "its own" memory, regardless of any software sandboxing. This means that all sorts of sandboxing methods for javascript interpreters, bytecode interpreters, plugin architectures, etc are insecure. And the OS patches can't help here, because the sandbox isn't in protected memory.

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

#87

Post by confounded »

jenscow wrote: post #71
criddell wrote: post #61

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.

The private key used to sign code? No, that wouldn't be in the console at all.

I imagine they mean the decryption key (rather, the ‘private, encryption’ key).

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

#88

Post by infinite8s »

DrTung wrote: post #31
vinn124 wrote: post #14

Earlier 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!

Well that value has to still be read into the cache, since the "kern_mem[address]&0x100" calculation is speculatively carried out. I don't think the MMU can do any bit level computations.

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

#89

Post by msbarnett »

piinbinary wrote: post #48
loeg wrote: post #42

Earlier quoted context omitted.

There is almost certainly a branch predictor even in these simple ARM cores.

(Asking for my own edification) What does the output of branch predictor get used for in a CPU without speculation?

In a pipelined CPU, you want to start the memory fetches for which instructions to next feed into the instruction decoder, before the branch instruction has finished the execute stage. Otherwise every branch incurs a pipeline bubble.

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

#90

Post by userbinator »

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 at that point

Keep in mind that for a very long time, PCs and x86 CPUs were used in environments where either there was a single user with full access, or multiple users that aren't completely adversarial (look at Win95/98's multiuser security model, for example.) Memory protection and other security features served as a barrier to accidents and to "keep the honest honest", not determined adversaries.

They still are today, but this is very different from the shared servers/cloud computing environments which have now become common --- completely mutually untrusting users with possibly adversarial relationships are sharing the same hardware.

This is the reason why all the CPU manufacturers have had some variant of "as designed" in their public comments --- speculative execution was designed with the former model in mind, not the latter.

Post reply on HN