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

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

  • 1
    According to the researchers: At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown. – Janghou Jan 4 at 9:38
  • 1
    There is an example that you can steal a password with Javascript in a browser (Chrome/Firefox). – Janghou Jan 4 at 18:04
  • 4
    @alex2003super: Don't freak out. Though the scale of affected devices is staggering, the odds of you being actually affected by this issue in any real way are pretty low. And even if they weren't, freaking out wouldn't help. :) – Lightness Races in Orbit Jan 4 at 21:30
  • 1
    It seems that they are not vulnerable, here is a recent article on the subject raspberrypi.org/blog/… – Omar Elabd Jan 5 at 18:11
  • 5
    You might found this post interesting: raspberrypi.org/blog/… – npf Jan 5 at 19:22

According to ARM themselves, the Raspberry Pi's processor cores (for all versions) are not affected.

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 Pis are:

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

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, at the present time, no Raspberry Pi devices are believed to be vulnerable to either Spectre or Meltdown.

  • I wonder if the changes to the Linux kernel that are required on other architectures will be pushed out to the versions of Linux that run on the Raspberry Pi? Supposedly these changes will slow down the system so maybe the RP will be affected even though the patches aren't needed. – Bobby Durrett Jan 4 at 22:09
  • 4
    The kernel patch detects what processor it's running on and automatically disables itself if it's not an affected model. Additionally the kernels for Raspberry Pi (and most other single-board computers) are built specifically for the hardware available, and there's no reason for the maintainers to include or enable the patch in question. – Perkins Jan 4 at 23:07
  • 1
    @BobbyDurrett, the Meltdown changes to the kernel are sitting in the x86-specific section of the codebase. The Spectre-related changes are all over the place, but most of them are in processor-specific sections of the code, or are handled by the compiler. Some bits, such as structural changes to the networking code, may leak into the Pi, but most of them won't. – Mark Jan 7 at 7:17
  • Thanks for the comments. It is interesting to think about which parts of the Linux kernel code are processor specific. I guess with an operating system that runs on a lot of different types of CPUs you have to do a good job of splitting out the code that is specific to each processor. – Bobby Durrett Jan 8 at 15:40

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.

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.

  • "Now, if two branches share the same predictor state, you can measure which way a particular branch has taken in the very recent past." How do you do this without speculative execution? – Peter Taylor Jan 5 at 23:02
  • @PeterTaylor these ARM CPUs have branch predictor, and therefore, they have speculative execution. What they are missing is out-of-order execution. – juhist Jan 5 at 23:19
  • They are documented to have speculative instruction fetching, but that isn't speculative execution. It's a fair point that it may still be possible to use it as an oracle. – Peter Taylor Jan 6 at 8:07
  • Even speculative fetch may be enough, as there will be a minor but measurable latency difference. – juhist Jan 6 at 9:16
  • Linux was already adding kernel address randomization; you can't predict the address of a branch. – MSalters Jan 7 at 14:01

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.