Raspberry Pi 4 missing firmware mitigation for Spectre v4

[lilyanatia]

Describe the bug
the Raspberry Pi 4's Cortex-A72 cores are vulnerable to Spectre v4 (Speculative Store Bypass, CVE-2018-3639). according to ARM, there's a firmware mitigation available for this vulnerability, but the mitigation seems to not be present on the Raspberry Pi 4.

To reproduce

1. download and build https://github.com/google/safeside
2. run the spectre_v4 demo

Expected behaviour

Leaking the string: Does not converge

Actual behaviour

Leaking the string: It's a s3kr3t!!!
Done!

System

• Which model of Raspberry Pi?
  Pi 4
• Which OS and version (cat /etc/rpi-issue)?
  Arch Linux ARM aarch64
• Which firmware version (vcgencmd version)?

Jul 13 2020 13:56:29
Copyright (c) 2012 Broadcom
version adcebbdb7b415c623931e80795ba3bae68dcc4fa (clean) (release) (start_x)

• Which kernel version (uname -a)?

Linux marten 5.8.0-1-ARCH #1 SMP Sun Aug 9 00:03:44 UTC 2020 aarch64 GNU/Linux

[6by9]

The linked page appears to say

For Cortex-A57 and Cortex-A72:

    Set bit 55 (disable load pass store) of CPUACTLR_EL1 (S3_1_C15_C2_0).

so I guess that needs to go into the ARM stub.

The issue is likely to be that this has a significant performance hit for all those who don't care about Spectre, so you now have to gain another version of the stub.

[lilyanatia]

The issue is likely to be that this has a significant performance hit for all those who don't care about Spectre, so you now have to gain another version of the stub.

maybe there could be a config.txt option to enable or disable it?

[6by9]

maybe there could be a config.txt option to enable or disable it?

Yes, things are possible, it just becomes further maintenance overheads.

You can already override the built-in stubs by adding an appropriate file (probably armstub8-gic.bin in your case) to /boot. That's why I was looking for the stub source files - now found https://github.com/raspberrypi/tools/tree/master/armstubs

[lilyanatia]

I built armstub8-gic.bin with the following changes:

diff --git a/armstubs/armstub8.S b/armstubs/armstub8.S
index f85eb521..188c0d55 100644
--- a/armstubs/armstub8.S
+++ b/armstubs/armstub8.S
@@ -65,6 +65,9 @@
 #define SCR_VAL \
     (SCR_RW | SCR_HCE | SCR_SMD | SCR_RES1_5 | SCR_RES1_4 | SCR_NS)
 
+#define CPUACTLR_EL1		S3_1_C15_C2_0
+#define CPUACTLR_EL1_DLPS	BIT(55)
+
 #define CPUECTLR_EL1		S3_1_C15_C2_1
 #define CPUECTLR_EL1_SMPEN	BIT(6)
 
@@ -124,6 +127,10 @@ _start:
 	mov x0, #CPUECTLR_EL1_SMPEN
 	msr CPUECTLR_EL1, x0
 
+	/* mitigate Spectre v4 */
+	mov x0, #CPUACTLR_EL1_DLPS
+	msr CPUACTLR_EL1, x0
+
 #ifdef GIC
         bl      setup_gic
 #endif

and after booting with that armstub, the spectre_v4 demo does gives the desired result ("Does not converge").

[6by9]

Thanks. I didn't know your knowledge level, but provided the links in case you could make use of them.

Feel free to create a PR for the stub. Ideally wrapped in a #ifdef so that it can be built only when desired. We always prefer to provide the correct attribution for contributions to the system.

Do you have any numbers on the impact that this mitigation has? I know some of them on x86 were HUGE, but I haven't been following this one.

[lilyanatia]

PR created: raspberrypi/tools#115

Do you have any numbers on the impact that this mitigation has?

so far all the testing I've done shows no impact other than Spectre v4 no longer working. do you have any recommendations of benchmarks that would be likely to show a difference?

[alanbork]

personally I'd want ZERO impact before enabling this by default. How many of us are using our Pi's in a multi-user environment?

[lilyanatia]

the PR wouldn't enable the mitigation by default (it's wrapped in a #ifdef). enabling it by default would definitely require more testing to determine what, if any, performance impact it has.

the PR wouldn't enable the mitigation by default (it's wrapped in a #ifdef)

What PR? If you mean the code above, it's not wrapped in an ifdef - the one ifdef shown sets up the GIC, if GIC mode is enabled.

[lilyanatia]

raspberrypi/tools#115, which is linked three comments above yours.

[AaronDewes]

According to this: https://github.com/speed47/spectre-meltdown-checker, the Raspberry Pi 4 is also vulnerable to CVE-2018-3640.

[lilyanatia]

it is, but ARM says:

This side-channel can be used to determine the values held in system registers that should not be accessible. While it is undesirable for lower exception levels to be able to access these data values, for the majority of system registers, the leakage of this information is not material.

and

Although Arm is addressing this issue in new CPU releases, in general, it is not believed that software mitigations for this issue are necessary.
For system registers that are not in use when working at a particular exception level and which are felt to be sensitive, it would in principle be possible for the software of a higher exception level to substitute in dummy values into the system registers while running at that exception level. In particular, this mechanism could be used in conjunction with the mitigation for Variant 3 to ensure that the location of the VBAR_EL1 while running at EL0 is not indicative of the virtual address layout of the EL1 memory, so preventing the leakage of information useful for compromising KASLR.

mitigating CVE-2018-3640 would probably require changes to the Linux kernel, rather than firmware, and probably isn't worth the trouble.

[ell1e]

Any updates on this? People are using the Raspberry increasingly for normal desktop tasks, so this seems like it should be fixed (with the secure variant being the default). Does the Linux kernel contain the necessary mitigations as well?

[alanbork]

idk, pi4 is pretty slow as a desktop os, I'd certainly prefer it not the default, or at the least very easy to switch.