Hacker News Reader

Comment by ploxiln | Hacker News Reader

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 simpler arm cores. Instructions are processed in parallel when possible, but not before dependencies, including branch decisions.

EDIT: under "What is speculation?" branch prediction is described. Then in the conclusion: "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."

View on HN

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

One could argue that CPUs without branch prediction are not modern in the sense of "modern, state of the art design". The fact that they still produce,e.g. 8051, even "new" overall designs, doesn't make the 8051 modern.

Branch prediction is neither new nor modern. Modern state of the art design doesn't actually do branch prediction in hardware at all. I mean look at all the ideas from VLIW architecture, no hardware - no problems.

You're being pretty silly by zeroing in on the word modern and then using an equally silly redefinition of it yourself.

Branch prediction isn't new, you're right. But VLIW instructions are equally unmodern and are entirely orthogonal to speculative execution. Sufficiently smart compilers are also no substitute for runtime analysis.

My CS book (Bryant and O'Hallaron, 2003, p. 399) says Control Data 6600 in 1964 was the first processor w out of order executuon, considered exotic until RS/6000 by IBM in 1990/PowerPC 601 in 1993.

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

Ah, that's good to know ... a comment below mentioned a "BTAC" (branch target access cache).

Is it just used for getting instructions into the L1i cache then?

(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

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.

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.

Yeah, it's not 100% obvious to me that you couldn't stage some variant of Spectre against even this more limited form of speculation.

In the comments on the article the author argues: "Why don’t speculative instruction (and data) fetches introduce a vulnerability? Because unlike speculative execution they don’t lead to a separation between a read instruction and the process (whether a hardware page fault or a software bounds check) that determines whether that read instruction is allowed."

but that would seem to be confusing the details of Spectre with Meltdown (which is happening a lot right now). Spectre doesn't depend on unauthorized reads succeeding.

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.

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

Here's what I'm trying to figure out. Let's say there's a JIT-generated instruction that I, an attacker, am interested in learning but cannot directly read from my position in the sandbox. If I can influence the instruction fetch speculator to issue a load for that instruction, then AFAICT it doesn't matter that it never makes it as far as the execute stage -- merely the act of fetching it for decode will have had a side-effect I can probably exploit into determining what it was.

Oh yeah you can do that, but I'm not sure if you can extract something useful out of this. Basically you can know whether or not a branch was speculatively loaded by timing the time it takes to go over it (if it was loaded by mistake it'll slow down execution). But then where do you go from there? Execution timings are not supposed to be secret.

I can't really imagine how you can construct an attack based on that, but maybe I lack imagination.

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

In an in-order CPU, you can still use a branch predictor to predict what to fetch and decode, so that you don't stall waiting for instruction fetch to finish after you resolve the branch.

In practice, advanced in-order designs contain more local reordering mechanisms, e.g. in the load/store unit, but they lack the unified global abstraction of a reorder buffer. The most successful timing attacks involve a mis-speculated load, so they wouldn't apply to these mechanisms, but it's not completely out of the question that they are also an effective side-channel.

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.

Pipelined processors would slowed down considerably without branch prediction: every branch (= loop iteration) would stall the pipeline and instruction prefetch. 20-25% of instructions are branches, so this would mean a 5-10 clock cycle pause every 4 or 5 instructions.

(Simplest cores have only static branch prediction though)

Yes. The reference manuals for the cores indicate that they all do.

rpi 1: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/dd...

rpi 2: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0464d/DD...

rpi 3: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500d/DD...

As others have indicated further down, though, it won't open up much of a vulnerability unless they are speculatively fetching memory.

I'm not arguing that R-Pi's are vulnerable to Spectre.

You're arguing that this article does not cover Spectre.

It does ... it just doesn't have to fully describe spectre to show why the raspi is not affected.

Reply on news.ycombinator.com