Is the Raspberry Pi vulnerable to the Spectre or Meltdown exploit?

Question

There are two new serious security flaws discovered, Spectre and Meltdown.

Is the Raspberry Pi vulnerable for Spectre and/or Meltdown?

Answer 1

According to ARM themselves, the processor cores used in all models before the Pi 4 are not vulnerable.

The majority of Arm processors are not impacted by any variation of this side-channel speculation mechanism. A definitive list of the small subset of Arm-designed processors that are susceptible can be found below. [see link for the table]

The processor cores used by the older Pis are:

• Pi 1 and Zero (W): ARM11

• Pi 2 V1: ARM Cortex-A7

• Pi 2 V1.2 and Pi 3: ARM Cortex-A53

None of the above cores are listed as vulnerable to any version of the attack (they are not listed at all, in fact, because there is no known vulnerability to these attacks).

The Raspberry Pi 4 uses the Cortex-A72, which is listed as vulnerable to variants 1, 2, 3a and 4. As stated in Is the Raspberry Pi 4 vulnerable to the Spectre exploits?, Raspbian contains software mitigations to these vulnerabilities, so the risk of exploitation should be low. Other operating systems may not contain appropriate mitigations, and while ARM say a hardware mitigation has been released for the Cortex-A72, it is unclear whether this has been applied to the Pi 4.

Note that Variants 1 and 2 (CVE-2017-5753 and CVE-2017-5715) are known as Spectre, and Variants 3 (CVE-2017-5754) and 3a (a related attack investigated by ARM) are called Meltdown. Therefore, none of the Raspberry Pi devices before Pi 4 are believed to be vulnerable to either Spectre or Meltdown.

Answer 2

The Pi (all versions) is not vulnerable.

Spectre and Meltdown both require out-of-order execution. The Cortex-A7 used in the early Pi 2 and the Cortex A53 used in the later Pi 2 and the Pi 3 is a strictly in-order architecture. The ARM11 used in the Pi 1 is partially out-of-order, but not in a way that permits Spectre or Meltdown to work.

ARM confirms this: only a very limited subset of ARM processors have hardware that makes them vulnerable to Spectre, an even more limited subset are vulnerable to Meltdown, and it's believed that all of them permit mitigation of the threat.

Answer 3

I'd like to offer my different take on this.

About Meltdown, it's a very specific vulnerability in some processors, so if ARM says the CPU in Raspberry Pi is not vulnerable, then it can probably be trusted.

However, Spectre is a more general vulnerability. So far, only two variants have been demonstrated but I'm pretty sure there are more variants. The fault in the CPU is that branch predictor state is not flushed when doing a context switch, and that branch predictor state is indexed by the low-order bits of the branch instruction address, and not tagged at all. So you may have two branches sharing the same branch predictor state, even across process boundaries.

I'm very confident that the CPU in all Raspberry Pi models is similar to practically all other CPUs out there in that the branch predictor is just a large array of 2-bit saturating counters (strongly taken, weakly taken, weakly not taken, strongly not taken). The index to this array is the low-order bits of the branch instruction address, and there is no tag, and this predictor state is never flushed.

Now, if two branches share the same predictor state, you can measure which way a particular branch has taken in the very recent past. The information leak of Spectre is thus there! If you can reliably trigger the browser to execute some code branching on your password from JavaScript, and measure which ways the branches have gone, you could indeed extract the password. Now this is an extreme example, nobody sane would branch on every single bit of your password in a manner that can be triggered from JavaScript, but this demonstrates the problem.

Don't believe everything ARM says. What ARM means is probably that the exploits Google have developed don't work on these ARM CPUs. It does not mean that they would be invulnerable to Spectre. Some other kind of exploit might work.

See this question: https://security.stackexchange.com/questions/176678/is-branch-predictor-flush-instruction-a-complete-spectre-fix and understand the implications of its answer. A rogue JavaScript code running in your browser can due to Spectre measure which ways other branches in the process have gone. Even a branch predictor flush instruction won't fix this rogue JavaScript problem, unless the browser actively flushes the branch predictor before running untrusted code.

Spectre will be with us for a very, very long time, as branch predictor using 14 bits as index isn't tagged with the remaining 18 bits of a 32-bit address space, because it would then require 20 bits (2 bits saturating counter, 18 bits tag) instead of just 2 bits. This would multiply the branch predictor size by ten! I'm expecting the CPU manufacturers to add a branch predictor flush instruction that works even in user space without special privileges and the kernel to use it when context switching and the user space to use it when running untrusted JITed code. This would fix most Spectre problems in practice, but in theory, not all of them.