Is the new Raspberry Pi 4 vulnerable to Meltdown and Spectre attacks?

[nuzada]

Is the new Raspberry Pi 4 vulnerable to Meltdown and Spectre attacks?

[gkaiseril]

Most viruses are machine dependent and this virus as many rely on the Intel and AMD family of chips. Since the Pi uses the ARM processor, the machine code is not compatible with Intel and AMD systems.

[bensimmo]

It should be as it uses the A72, the OS or whatever may stop that.

[Heater]

gkaiseril,

Most viruses are machine dependent ...

True.

...and this virus as many rely on the Intel and AMD family of chips

Not true.

These attacks depend of processor optimization features that can be present in any processor architecture.

I have no idea if our Pi's ARM cores employ such features though, or if anyone has yet managed to exploit them on other than Intel/AMD machines.

Since the Pi uses the ARM processor, the machine code is not compatible with Intel and AMD systems.

Given that Meltdown and/or Spectre attacks have been demonstrated in Javascript it's clear that actual machine instruction set is not critical to their operation.

Anyway, I'm not about to worry about it.

[cspan]

I am concerned about this too. When Eben penned this:

https://www.raspberrypi.org/blog/why-ra ... -meltdown/

... I was heartened.

However, in the PDF issued by pi3g.com (Inside the Raspberry Pi 4), on page 6, it mentions that the new core has "out-of-order execution ('pipelined processor with deeply out of order, speculative issue 3-way superscalar execution pipeline')"

It isn't 100% clear to me what this exactly means, but it does contain the terms "speculative" and "execution" - without a negative modifier. It's a bit concerning, and I'd like clarificiation. Hard to believe that RPT would concede security for performance, after having proudly pointed out their immunity to this chip vulnerability.

[ejolson]

It should be as it uses the A72, the OS or whatever may stop that.

According to Wikipedia

ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected. The ARM Cortex-A75 core is affected directly by both Meltdown and Spectre vulnerabilities, and Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72 and Cortex-A73 cores are affected only by the Spectre vulnerability.[61] This contradicts some early statements made about the Meltdown vulnerability as being Intel-only.[73]

Therefore, it would appear the Pi 4 is susceptible to Spectre but not Meltdown.

[jerrm]

Cortex A72 is potentially at risk, no idea about the Pi's specific variation.

If the Pi revision susceptible, I would hope the mitigations are enabled by default.

See https://developer.arm.com/support/arm-s ... -arm-cores

[Andyroo]

There was an interesting note on how effective these attacks could be last year:

In fact, I doubt we will ever see a lot of in-the-wild malware using the Meltdown or Spectre exploits. Memory-read attacks simply aren't that attractive to most attackers: they don't allow an attacker to run arbitrary code on a targeted system, nor do they give the attacker access to stored data they are interested in. It is telling that Heartbleed, an unrelated attack that also allowed access to large chunks of memory, was not exploited widely in the wild, if it even was at all.

Taken from https://www.virusbulletin.com/blog/2018 ... r-spectre/

I know there are ‘working samples’ at https://meltdownattack.com/ but I’m more concerned how stable Buster will be

[Andyroo]

Following on from my last sentence:

Please note that security updates for testing distribution are not yet managed by the security team. Hence, testing does not get security updates in a timely manner. You are encouraged to switch your sources.list entries from testing to stretch for the time being if you need security support. See also the entry in the Security Team's FAQ for the testing distribution.

Taken from https://www.debian.org/releases/testing/

[ejolson]

There was an interesting note on how effective these attacks could be last year:

In fact, I doubt we will ever see a lot of in-the-wild malware using the Meltdown or Spectre exploits. Memory-read attacks simply aren't that attractive to most attackers: they don't allow an attacker to run arbitrary code on a targeted system, nor do they give the attacker access to stored data they are interested in. It is telling that Heartbleed, an unrelated attack that also allowed access to large chunks of memory, was not exploited widely in the wild, if it even was at all.

Taken from https://www.virusbulletin.com/blog/2018 ... r-spectre/

I know there are ‘working samples’ at https://meltdownattack.com/ but I’m more concerned how stable Buster will be

I think these side-channel information leaks mostly affect cloud providers by demonstrating that partitioning an Intel Xeon server into multiple virtual machines doesn't provide anywhere near the isolation and security that the marketing types wanted.

At this point various mitigations that negatively affect performance have been added upstream to Linux and applications that require additional security. Therefore, the standard mitigations are surely in place for Raspbian. In the future, I suspect one may see specialized hardware designed for security-sensitive code paths. For example, if it weren't for Oracle cancelling future development, the SPARC M8 security-in-silicon encrypted memory seems like a promising way to avoid many side channel attacks.

Since the secure sharing of a single Raspberry Pi among adversarial users is generally not an issue, the main vulnerability for the Pi 4 occurs when a web browser downloads a page that contains WebAssembler or JavaScript that employs the Spectre side-channel to read privileged memory. Unless you are a government-class espionage target, the chance of accidentally downloading such a webpage and it actually extracting damaging information is minimal. If you are such an espionage target, it might be better to stick to the 3B+ or pencil and paper.

[Andyroo]

The problems then becomes once a third party has access to your machine you can become a bot and help mine them money or take part in a DOS attack etc etc and that’s not even thinking about being a platform for attacks inside the network for bank details etc.

It’s just another worry about connecting ANY computer to the Internet nowadays and I’m glad I do not have Intel / AMD support concerns anymore. (I’m also only up to 3B+ at the top end of the Pi boxes here - so I can wait).

Wonder if Smiths still sell 4B pencils

[DavidS]

I do not understand why it would matter if it is vulnerable to a Spectre attack, that is just a way of getting at information that is not accessible from normal modes of operation. So what information would you have on an internet connected machine that would matter in such a way. I guess it is technically possible to use such a thing to inject code into protected memory, though no one has yet done that with it.

As for Meltdown attacks, well I have not heard any news suggesting that the Cortex-A72 is vulnerable, I am not 100% sure though. And again if you have data that it matters if is read from a different context then there is a problem with your setup. What would be the use of such a thing?

[DavidS]

Put another way, it is normal for most systems to allow read access between protected contexts. There should be no data anywhere on your system that if read from an unknown context could be a vulnerability in any way. So no passwords in raw text or in a form that is easy to decrypt (and ideally only in non reversible encryption, the only reversible form should be in the human memory).

And no data that could potentially be of importance on a level that others should not have it should ever be on a computer that is connected to the internet (unfortunately our banking systems break this rule badly).

[klockstone]

https://en.wikipedia.org/wiki/Meltdown_ ... erability) says:

... Also, no Raspberry Pi computers are vulnerable to either Meltdown or Spectre, except the newly-released Raspberry Pi 4, which uses the ARM Cortex-A72 CPU.

If there has been some work-around, we need to be told and Wikipedia updated.

Keith.

[Tritonio]

Maybe someone would like to run this https://github.com/speed47/spectre-meltdown-checker on a RPi 4?

[CueCueBangBang]

I ran it on my pi 4. https://streamable.com/h87h8 -- https://pastebin.com/GLRy6uWK

[CueCueBangBang]

Also gave this a test with Manjaro ARM. It gave completely different results, leading me to believe they put a patch in the OS of Raspbian Buster. https://pastebin.com/8curyTfY

[ejolson]

Also gave this a test with Manjaro ARM. It gave completely different results, leading me to believe they put a patch in the OS of Raspbian Buster.

It would be interesting to run the test on the Pi 3B+ to see whether anything unexpected shows up.

[pica200]

If i had to guess this may be a result of Raspian running a 32 bit kernel and reporting the wrong CPU as a result but dunno. Yes, the A72 is definitely vulnerable to Spectre but not Meltdown. Unless you store sensitive data or do online banking or similar with multiple tabs open you don't need to worry about Spectre. It requires a fair amount of knowledge and effort to exploit properly.

I would even just disable all mitigations because the RPi is not meant to be secure anyway and speed is more important (imho).

[graysky]

On my x86_64 machine, simply running /usr/bin/lscpu lists out some info"

Code: Select all

% lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   39 bits physical, 48 bits virtual
CPU(s):                          8
On-line CPU(s) list:             0-7
Thread(s) per core:              2
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           60
Model name:                      Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
Stepping:                        3
CPU MHz:                         1835.619
CPU max MHz:                     4400.0000
CPU min MHz:                     800.0000
BogoMIPS:                        8003.27
Virtualization:                  VT-x
L1d cache:                       128 KiB
L1i cache:                       128 KiB
L2 cache:                        1 MiB
L3 cache:                        8 MiB
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fx
                                 sr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_go
                                 od nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
                                 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsa
                                 ve avx f16c rdrand lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow v
                                 nmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt 
                                 dtherm ida arat pln pts md_clear flush_l1d

On my RPi4 I see none of this... not sure if that gives a definitive answer but adds to the discussion. On the RPi4:

Code: Select all

% lscpu
Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               3
Model name:          Cortex-A72
Stepping:            r0p3
CPU max MHz:         1500.0000
CPU min MHz:         600.0000
BogoMIPS:            270.00
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

Would be interesting to see if someone running aarch64 on the RPi4 gets output related to the topic.

[DougieLawson]

This is from a RPi3B Raspbian system running the RPF 4.19.71-v8+ 64-bit kernel.

Code: Select all

pi@endeavour:~$ lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               4
Model name:          Cortex-A53
Stepping:            r0p4
CPU max MHz:         1200.0000
CPU min MHz:         600.0000
BogoMIPS:            38.40
Flags:               fp asimd evtstrm crc32 cpuid
pi@endeavour:~$ cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 1
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 2
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 3
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

Hardware        : BCM2835
Revision        : a02082
Serial          : 0000000018ae9924
Model           : Raspberry Pi 3 Model B Rev 1.2

Haven't got a RPi4 running that yet.

[pica200]

Output on Manjaro ARM is the same (updated 1-2h ago):

Code: Select all

[blub@raspi4 Schreibtisch]$ cat /proc/cpuinfo 
processor	: 0
BogoMIPS	: 108.00
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

processor	: 1
BogoMIPS	: 108.00
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

processor	: 2
BogoMIPS	: 108.00
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

processor	: 3
BogoMIPS	: 108.00
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3

Hardware	: BCM2835
Revision	: c03111
Serial		: 10000000d14xxxxx
Model		: Raspberry Pi 4 Model B Rev 1.1
[blub@raspi4 Schreibtisch]$ lscpu
Architektur:                   aarch64
CPU Operationsmodus:           32-bit, 64-bit
Byte-Reihenfolge:              Little Endian
CPU(s):                        4
Liste der Online-CPU(s):       0-3
Thread(s) pro Kern:            1
Kern(e) pro Socket:            4
Sockel:                        1
Anbieterkennung:               ARM
Modell:                        3
Modellname:                    Cortex-A72
Stepping:                      r0p3
Maximale Taktfrequenz der CPU: 2000,0000
Minimale Taktfrequenz der CPU: 600,0000
BogoMIPS:                      108.00
Markierungen:                  fp asimd evtstrm crc32 cpuid

[ejolson]

It requires a fair amount of knowledge and effort to exploit properly.

After sufficiently user-friendly software has been written, it takes almost no knowledge for a criminal to use it.

The only way to prevent the computer illiterate from exploiting security vulnerabilities such a Spectre and Meltdown would be to outlaw the use of mice. Then criminals will be the only ones who still own a mouse and consequently easy to identify and arrest.

[Heater]

It may require a fair amount of knowledge and effort to exploit but such exploits when created are traded on the "dark web". I'm sure there are plenty of criminals who can get by without a mouse.

[pica200]

There are proof of concepts out there but they run directly for you to test if your CPU is vulnerable. If an attacker can already execute code on your machine you have a more serious problem. As far as i know there is no browser based proof of concept yet and all major browsers have workarounds to make it way harder to exploit.