Live data from Hacker News

Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

raspberrypi.org

141–150 of 232 posts

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

#141
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!…

Thanks for the confirmation and inside info!

Yesterday we only guessed it https://news.ycombinator.com/item?id=16069740 based on ARM CPU list,

the RPi 1-3 CPUs

  ARM11, Cortex-A7, Cortex-A53
aren't in the list.

Affected ARM cores:

  Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex A15, 
  Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73, Cortex-A75
https://developer.arm.com/support/security-update

(I tried to post it 3 hours ago, but HN is rate-limiting my posts, oh well)

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

#142
post #139

Earlier quoted context omitted.

Sorry. Is this crude? Don't really understand down votes.

I suspect the downvotes are because the comment is pretty light on substance as well as being a tired meme. HN members typically value good, substantive, constructive comments and try to keep the signal to noise ratio up as best they can. https://news.ycombinator.com/newsguidelines.html

Thank you.

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

#143
Off topic, but I haven't seen this discussed anywhere yet. My understanding is that font files can contain complex instruction sequences to control exactly how a font is rendered. I believe Windows implements a kernel space VM to execute these instructions. I know variants 1 and 2 did not necessarily require eBPF but that it made the attack simpler because the desired instruction sequences could be injected directly into kernel space (rather than finding existing sequences in the code base). It seems that in theory font rendering could serve a similar function on some platforms.

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

#144
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!…

At least in the case of Cortex A-7, there's about 2-3 cycles (maybe 3-4 instructions with dual-issuing) before a branch mis-predict causes a pipeline flush. You can maybe fit a couple of loads into that time, and maybe one of them will result in a Dcache fill. Other in-order cores in the Cortex-A line have similar Dcache side-effect under mis-predict. It's not clear whether this actually leads to speculated Dcache fills, though.

So it's possible that some of the Raspberry Pi versions are in fact vulnerable to (much weaker versions of) Meltdown and Spectre.

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

#145

Earlier quoted context omitted.

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.

If you're doing speculative memory fetches, wouldn't that also leave a measurable impact on the cache? Simply instead of MOV AX, [something that depends on secret value] as in the original Meltdown paper you'd need to use JMP [something that depends on secret value] to trigger the memory fetch in a branch that's not going to be used.

Not if you're just trying to avoid a bubble in you pipeline and not actually executing the opcodes speculatively. In this situation the code will be loaded (and probably decoded etc...) but not executed before the CPU made sure that the branch was actually taken. If it's not the pipeline is flushed and a bubble is introduced after all. It's not as efficient as executing speculatively out of order but at least if you predict correctly you avoid the cost of stalling the CPU on every conditional branch until it's resolved.

ARM also has an other trick for that, every opcode in the (full, non-Thumb) instruction set has a condition code that can let you execute an instruction conditionally based on the flags state without requiring an explicit branch. This way from the CPU perspective the flow of the code is linear, it's only late in the pipeline that the condition code is evaluated and the instruction discarded if it doesn't mach the flags. This way you're sure you'll never have a bubble no matter what, although the downside is that you end up fetching instructions that may end up not being executed so it's only worth it for "short" branches.

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

#146
post #38
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…

A lot of the cheaper Pi-like boards also aren't affected for the same reason, as are lower-end Android phones. The articles claiming it affected every modern CPU were basically mistaken. It was an easy mistake to make, given that ARM's announcement only listed the cores that were affected and had a little note saying everything not listed was unaffected by both Meltdown and Spectre. (There is precisely one ARM-designed core that is affected by Meltdown, a high-end one so new that no chips based on it have been released yet.)

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

#147
post #101
post #18

Earlier quoted context omitted.

Well, the vulnerabilities are directly connected to performance-enhancing architectural features, so...

Which is why i said technical details aside. I think it's interesting, you are not just paying for speed, you are paying for a compromise, because the speed is gained through complexity, which not only increases the chance of error (by design or implementation) but in the case of a high degree of speculative execution can translate into worse performance per watt. In short, it's the whole "more is less" thing.

> you are paying for a compromise

Very good point. Apparently including at least one compromise that most people (probably including the engineers who designed the CPUs) didn't know they were making.

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

#148
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 rules of safe speculation is that you can't speculate an instruction unless you can prove it has no observable side-effects (ie possibly faulting, or in this case, ending up in cache), or that the side-effects are the precisely the same whether you speculate it or not (where "precisely the same" generally includes some notion of ordering of side-effect occurrence. i'm not going to get into all the various intricacies)

IE

  a+b -> safe to speculate, has no side effects
  load a -> generally unsafe, has possible observable side effects

  if foo:
    load a
  else
    load a 
  -> safe to speculate load a to right above the if, it must always be executed, and in this example, side-effects will be the same.
 
  if foo:
    load a
  -> not safe to speculate load a above the if, it may not execute
Compilers generally did not speculate loads, mainly because they can fault at that level[1]. The fault comes from the processor though.

So processors were/are assuming that speculation of loads, calls, etc, had no side effects because they could "throw away the results". As the processor controlled the faulting, it could just throw away the fault and pretend it never happened.

These two attacks are just proving that is not true, and the side-effects of computation themselves are observable.

The end result should be the same. Processors speculate more like compilers do: only in safe situations.

The idea that you have to give up all speculative execution seems very wrong.

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.

The upshot is the most likely outcome is that both processors and compilers will work harder to speculate.

Compilers will get called upon to do more safe speculation.

Processors will have to grow the logic to determine when speculation is safe (or figure out a way to actually undo all side effects, which is fairly hard).

Now, the downside is the most useful speculation is obviously to hide load/store latency, and those things are the hardest to reason about safety.

But like i said, compilers have been doing it for many years at this point. Our hardware brethren just found out the hard way that they are likely to start having to do it too, and that there are more observable side-effects than they thought.

[1] Some JITs do it and catch the result in a fault handler if it turns out badly. I expect someone is going to discover ways to exploit all of these basically instantly. These will not be fixed by processor related fixes because they are not processor directed.

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

#150
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…

> 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 should know that, but, if the compiler already knows it, a runtime check can be skipped.

> Processors will have to grow the logic to determine when speculation is safe

In many cases, this would be as simple as flagging the micro-op as unsafe and pause the speculation at that point.

For Meltdown, the just-add-silicon approach could be to never share cache between privileged and unprivileged code. To extend that to Spectre, never share cache across different PIDs (but, then, the ISA will have to know what a PID is). Since that would reduce the effective cache effectiveness, caches will have to grow.

Fun times ahead.

Post reply on HN