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

171–180 of 232 posts

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

#171

Post by katastic »

ploxiln wrote: post #38
tptacek wrote: post #32

This is great, but remember that it covers Meltdown, not Spectre. Meltdown is the more immediate disaster, but Spectre is the more batshit vulnerability. You really want to get your head around: * The branch target injection variant of Spectre if you want to get a sense of how amazing this vulnerability is: you can spoof the branch predictor to trick a target process into running arbitrary code in its address space!…

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…

Old Atoms also don't have a branch predictor. The new ones might?

IIRC, they were basically "low power" versions of the desktop CPUs by ripping out all the expensive branch prediction / out-of-order speculation parts.

I used to know this more because I was reading intentionally on it, but old age and years passing kind of rots the memory.

[edit] Yep:

>every Intel processor since 1995 that implements out-of-order execution is potentially affected by Meltdown – except Itanium, and the Atom before 2013.

http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect...

So "every Intel CPU" is correct enough for the general public to scare most people (as it is potentially a huge problem), but it's incorrect in the sense it doesn't apply to ALL Intel CPUs. Atoms are very popular in netbooks. (And the Itaniums exception we can ignore because a handful of machines across the entire planet are running them.)

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

#172

Post by kevin_thibedeau »

phkahler wrote: post #52
loeg wrote: post #42

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! ;-)

Low end ARM parts keep track of branches to avoid purging cached pages that will be likely be needed soon. That allows them to have decent performance when executing from flash.

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

#173

Post by eximius »

CamperBob2 wrote: post #170
pilom wrote: post #105

Earlier quoted context omitted.

You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not.

You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not. What does that do, besides turn the exfiltration problem from an immediate one into a statistical one?

IF it can be turned into a statistical problem, it may become an infeasible attack. You'd have to run the whole attack (not just the last reading bit since that would bring it into the cache after the first read) many times to be able to ascertain the difference. Even then, the difference might be less than the noise from other processes on the system (I think 80 cycles was used in the PoC?).

Maybe there will end up being a new Jumping Around Kernal Address Space System (JAKASS - a cousin of Linux's FUKWIT patch) that periodically resets kernel ASRL to make it fully impossible.

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

#174

Post by aplorbust »

tptacek wrote: post #32

This is great, but remember that it covers Meltdown, not Spectre. Meltdown is the more immediate disaster, but Spectre is the more batshit vulnerability. You really want to get your head around: * The branch target injection variant of Spectre if you want to get a sense of how amazing this vulnerability is: you can spoof the branch predictor to trick a target process into running arbitrary code in its address space!…

How many RPi users are using this board to run untrusted code?

The RPi may mitigate risk of these attacks simply in the way it is used.

Perhaps hobbyists use it to run their own small programs, not random third party Javascript in an enormous web browser from some corporation.

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

#175

Post by astrange »

fyi1183 wrote: post #120
tptacek wrote: post #32

This is great, but remember that it covers Meltdown, not Spectre. Meltdown is the more immediate disaster, but Spectre is the more batshit vulnerability. You really want to get your head around: * The branch target injection variant of Spectre if you want to get a sense of how amazing this vulnerability is: you can spoof the branch predictor to trick a target process into running arbitrary code in its address space!…

If you don't feel overwhelmed enough by the misprediction variant of Spectre yet, consider that the cache side effect of speculation is actually desirable in most normal cases, because it helps prime caches with data that is likely to be used in the correct branch as well. Just turning it off is not the right way to solve this. Perhaps this will finally provide enough incentives to model data sensitivity in the type…

It would be hard to model data-dependent timing of an actual CPU. Integer division is variable time on lots of architectures, but on ARM even multiplication timing is data-dependent! And on desktops you could cause a even mov instruction to stall a few cycles if you can run something before it that uses all the renamed registers - there might be a way to turn this into data dependence and observe it from the perf counters…

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

#176

Post by astrange »

rbanffy wrote: post #150
DannyBee wrote: post #148

Earlier quoted context omitted.

It's not all that hopeless, actually. Let's ignore meltdown, which seems solvable in hardware with no obvious performance loss (assuming amd's existence proof is correct), and concentrate on spectre, which everyone thinks means the world is ending. One thing to note is that compilers have been safely speculating instructions for years. Shocking, i know :) Processors could too. They just weren't. One of the cardinal r…

> You only have to give it up in cases where there are possibly observable side-effects and it's not guaranteed they will always happen. > Compilers will get called upon to do more safe speculation Compilers can also emit code that minimizes those situations. Also, extending the ISA with an instruction modifier that signals that otherwise innocent instruction has indeed observable side effects (ideally the processor…

Intel CPUs do already have PCID (PID-tagged page table cache) to make switching processes cheaper.

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

#177

Post by gpderetta »

DannyBee wrote: post #148
tptacek wrote: post #32

This is great, but remember that it covers Meltdown, not Spectre. Meltdown is the more immediate disaster, but Spectre is the more batshit vulnerability. You really want to get your head around: * The branch target injection variant of Spectre if you want to get a sense of how amazing this vulnerability is: you can spoof the branch predictor to trick a target process into running arbitrary code in its address space!…

It's not all that hopeless, actually. Let's ignore meltdown, which seems solvable in hardware with no obvious performance loss (assuming amd's existence proof is correct), and concentrate on spectre, which everyone thinks means the world is ending. One thing to note is that compilers have been safely speculating instructions for years. Shocking, i know :) Processors could too. They just weren't. One of the cardinal r…

Considering that on average you have a branch every 5 instructions and the reorder buffer of high performance OoO CPU is in the order of a hundred of instruction, such a CPU is pretty much running under speculation all the time (often of multiple branches at the same time).

Not being able to fetch new cachelines when under speculation would be a huge blow, as exposing memory level parallelism is one of the most important features of OoO CPUs.

Edit: also fetching a cacheline is not really undoable as it is observable from other CPUs via the coherency protocol: i.e. while it might be possible to hide to the local cpu that a cacheline was loaded under a failed speculation, the effect can be still observed by another core by noticing that an exclusive line is now shared (by timing for example the latency of an atomic instruction)

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

#178

Post by cperciva »

tptacek wrote: post #162
sillysaurus3 wrote: post #156

Earlier quoted context omitted.

By the way, didn't cperciva point out this vuln way back in 2005? http://www.daemonology.net/papers/htt.pdf Actually that seems to be rather different, but still similar-ish. They both use threads to exploit memory caches in an unexpected way. I thought he deserved a mention since no one really took it seriously back then. https://it.slashdot.org/story/05/05/13/0520214/hyperthreadin... http://freerepublic.com/focus/f…

Cache timing goes back to at least 2005 with Osvik and Tromer. This isn't a simple cache timing bug, though.

Cache timing goes back to 2005 with Percival. I published a couple weeks before them. :-)

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

#179

Post by tathougies »

zackmorris wrote: post #138
ProblemFactory wrote: post #86

Earlier quoted context omitted.

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

Thank you, that was a succinct explanation of the difference between AMD/Intel and the order of speculation and protected memory access check for the Meltdown attack, and makes it easier to understand: https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... I see now why the Spectre attack is so serious (reading out of bounds within the same process memory). I feel like there may be ways to catch unallocated…

The slow context switching between processes has nothing to do with OS implementation. True context switching involves a page table flush. This is slow due to caching, independent of the OS. The only thing the OS can do is tell the processor which parts not to mark dirty, but -- as these attacks show -- this can expose vulnerabilities.

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

#180

Post by sitkack »

astrange wrote: post #175
fyi1183 wrote: post #120

Earlier quoted context omitted.

If you don't feel overwhelmed enough by the misprediction variant of Spectre yet, consider that the cache side effect of speculation is actually desirable in most normal cases, because it helps prime caches with data that is likely to be used in the correct branch as well. Just turning it off is not the right way to solve this. Perhaps this will finally provide enough incentives to model data sensitivity in the type…

It would be hard to model data-dependent timing of an actual CPU. Integer division is variable time on lots of architectures, but on ARM even multiplication timing is data-dependent! And on desktops you could cause a even mov instruction to stall a few cycles if you can run something before it that uses all the renamed registers - there might be a way to turn this into data dependence and observe it from the perf cou…

All shortcuts leak information. Anything with the equivalent of an early return leaks information.
Post reply on HN