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
    Commented Jan 4, 2018 at 9:38
  • 1
    There is an example that you can steal a password with Javascript in a browser (Chrome/Firefox).
    – Janghou
    Commented Jan 4, 2018 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. :) Commented Jan 4, 2018 at 21:30
  • 1
    It seems that they are not vulnerable, here is a recent article on the subject raspberrypi.org/blog/…
    – Omar Elabd
    Commented Jan 5, 2018 at 18:11
  • 5
    You might found this post interesting: raspberrypi.org/blog/…
    – pfm
    Commented Jan 5, 2018 at 19:22

3 Answers 3


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:

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.

  • 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. Commented Jan 4, 2018 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
    Commented Jan 4, 2018 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
    Commented Jan 7, 2018 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. Commented Jan 8, 2018 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? Commented Jan 5, 2018 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
    Commented Jan 5, 2018 at 23:19
  • 1
    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. Commented Jan 6, 2018 at 8:07
  • Even speculative fetch may be enough, as there will be a minor but measurable latency difference.
    – juhist
    Commented Jan 6, 2018 at 9:16
  • Linux was already adding kernel address randomization; you can't predict the address of a branch.
    – MSalters
    Commented Jan 7, 2018 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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