Aardappeltaart
Posts: 46
Joined: Wed Mar 02, 2016 11:32 am

RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 12:01 pm

I always consider this post by Eben as one of the most informative and best educational posts about modern CPU and (potential) security issues.

But now the RPI4 has out-of-order A72 cores, which have Speculative Processor Vulnerabilities (17/Jun/2019)

Code: Select all

Processor   Variant 1  Variant 2 Variant 3 Variant 3a Variant 4
Cortex-A72     Yes         Yes**     No**     Yes**        Yes

I do wonder if the Pi cores have hardware mitigations, mentioned in the linked page
However, an update for the latest release of the Cortex-A72 does include a hardware mitigation for this issue.

And what about software mitigations? On my Intel Ubuntu 1804 laptop:

Code: Select all

ls -1A /sys/devices/system/cpu/vulnerabilities
l1tf                                                                                                                                                                                         
mds                                                                                                                                                                                          
meltdown                                                                                                                                                                                     
spec_store_bypass                                                                                                                                                                            
spectre_v1                                                                                                                                                                                   
spectre_v2   

Code: Select all

cat /sys/devices/system/cpu/vulnerabilities/*                                                                                                                                   
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable                                                                                                                    
Mitigation: Clear CPU buffers; SMT vulnerable                                                                                                                                                
Mitigation: PTI                                                                                                                                                                              
Mitigation: Speculative Store Bypass disabled via prctl and seccomp                                                                                                                          
Mitigation: __user pointer sanitization                                                                                                                                                      
Mitigation: Full generic retpoline, IBRS_FW, STIBP: conditional, RSB filling 

RPI4

Code: Select all

ls -1A /sys/devices/system/cpu/vulnerabilities
cat /sys/devices/system/cpu/vulnerabilities/*

'/sys/devices/system/cpu/vulnerabilities/*': No such file or directory 

Does that mean there are no vulnerabilities in the RPI4 cores, or that there are no mitigations in place, or that info is simply missing at the moment?

fruitoftheloom
Posts: 20485
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 12:09 pm

Aardappeltaart wrote:
Sun Jun 30, 2019 12:01 pm
I always consider this post by Eben as one of the most informative and best educational posts about modern CPU and (potential) security issues.

But now the RPI4 has out-of-order A72 cores, which have Speculative Processor Vulnerabilities (17/Jun/2019)

Code: Select all

Processor   Variant 1  Variant 2 Variant 3 Variant 3a Variant 4
Cortex-A72     Yes         Yes**     No**     Yes**        Yes

I do wonder if the Pi cores have hardware mitigations, mentioned in the linked page
However, an update for the latest release of the Cortex-A72 does include a hardware mitigation for this issue.

And what about software mitigations? On my Intel Ubuntu 1804 laptop:

Code: Select all

ls -1A /sys/devices/system/cpu/vulnerabilities
l1tf                                                                                                                                                                                         
mds                                                                                                                                                                                          
meltdown                                                                                                                                                                                     
spec_store_bypass                                                                                                                                                                            
spectre_v1                                                                                                                                                                                   
spectre_v2   

Code: Select all

cat /sys/devices/system/cpu/vulnerabilities/*                                                                                                                                   
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable                                                                                                                    
Mitigation: Clear CPU buffers; SMT vulnerable                                                                                                                                                
Mitigation: PTI                                                                                                                                                                              
Mitigation: Speculative Store Bypass disabled via prctl and seccomp                                                                                                                          
Mitigation: __user pointer sanitization                                                                                                                                                      
Mitigation: Full generic retpoline, IBRS_FW, STIBP: conditional, RSB filling 

RPI4

Code: Select all

ls -1A /sys/devices/system/cpu/vulnerabilities
cat /sys/devices/system/cpu/vulnerabilities/*

'/sys/devices/system/cpu/vulnerabilities/*': No such file or directory 

Does that mean there are no vulnerabilities in the RPI4 cores, or that there are no mitigations in place, or that info is simply missing at the moment?

https://www.raspberrypi.org/forums/view ... 3&t=243594
Retired disgracefully.....

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23366
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 2:58 pm

Whilst these are technically vulnerabilities, have any of these been detected in actual malware? It's always seemed ferociously difficult to actually move from proof of principle to actually being able to compromise a system.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Heater
Posts: 13106
Joined: Tue Jul 17, 2012 3:02 pm

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 3:34 pm

Quite right James. There are a million other ways bad guys can get data out of you that do work and are used in the wild. Just check the news everyday of this or that new vulnerability being found or this or that site/service being infiltrated..

Whilst one is busy worrying about all of those, or better still keeping up with the news and taking precautions appropriately, Specter and Meltdown are very low on the list of security concerns.

echmain
Posts: 230
Joined: Fri Mar 04, 2016 8:26 pm

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 3:56 pm

Specter and Meltdown became extremely well known simply because their names invoke frightening images. Like something out of a Bond movie.

The pop media outlets caught on and ran with it.

Never let the facts get in the way of a good story.

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2074
Joined: Thu Jul 11, 2013 2:37 pm

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 4:08 pm

A72 is immune to Meltdown. A72 is vulnerable to Spectre, but this means context leakage in the same process space.

The practical upshot of this is that on A72, there is yet another way to exfiltrate data from the web browser via malicious javascript - that is mitigated against quite effectively via a) site/process isolation - each tab gets its own process cluster and b) recompiling with "CDSB" speculation barriers and retpolines enabled at critical points. Do both of these, and Spectre is relegated to an academic curiosity on Pi 4.
Rockets are loud.
https://astro-pi.org

lb
Posts: 261
Joined: Sat Jan 28, 2012 8:07 pm

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 5:17 pm

jdb wrote:
Sun Jun 30, 2019 4:08 pm
A72 is immune to Meltdown. A72 is vulnerable to Spectre, but this means context leakage in the same process space.

The practical upshot of this is that on A72, there is yet another way to exfiltrate data from the web browser via malicious javascript - that is mitigated against quite effectively via a) site/process isolation - each tab gets its own process cluster and b) recompiling with "CDSB" speculation barriers and retpolines enabled at critical points. Do both of these, and Spectre is relegated to an academic curiosity on Pi 4.
I guess the question is: is Raspbian Buster compiled with tne necessary mitigations? And again, the question remains if the A72 cores have some of the hardware mitigations in place. These vulnerabilities are a significant issue if that isn't the case.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23366
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 5:32 pm

lb wrote:
Sun Jun 30, 2019 5:17 pm
jdb wrote:
Sun Jun 30, 2019 4:08 pm
A72 is immune to Meltdown. A72 is vulnerable to Spectre, but this means context leakage in the same process space.

The practical upshot of this is that on A72, there is yet another way to exfiltrate data from the web browser via malicious javascript - that is mitigated against quite effectively via a) site/process isolation - each tab gets its own process cluster and b) recompiling with "CDSB" speculation barriers and retpolines enabled at critical points. Do both of these, and Spectre is relegated to an academic curiosity on Pi 4.
I guess the question is: is Raspbian Buster compiled with tne necessary mitigations? And again, the question remains if the A72 cores have some of the hardware mitigations in place. These vulnerabilities are a significant issue if that isn't the case.
No, IMO they are not a significant issue, even if the mitigation isn't built in to the kernel or the silicon. because, as above, AIUI there is no malware that uses this attack vector.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Aardappeltaart
Posts: 46
Joined: Wed Mar 02, 2016 11:32 am

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 6:24 pm

On my AMD Ubuntu 18.04:

Code: Select all

cat  /sys/devices/system/cpu/vulnerabilities/*
Not affected
Not affected
Not affected
Not affected
Mitigation: __user pointer sanitization
Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
As you can see, Meltdown is only an issue on Intel, and Ubuntu is nicely reporting that. compare it with OP.
jdb wrote:
Sun Jun 30, 2019 4:08 pm
The practical upshot of this is that on A72, there is yet another way to exfiltrate data from the web browser via malicious javascript - that is mitigated against quite effectively via a) site/process isolation - each tab gets its own process cluster and b) recompiling with "CDSB" speculation barriers and retpolines enabled at critical points. Do both of these, and Spectre is relegated to an academic curiosity on Pi 4.
AMD ubuntu 1804

Code: Select all

dmesg | grep retpoline
[    0.028872] Spectre V2 : Mitigation: Full AMD retpoline
RPI4

Code: Select all

dmesg | grep retpoline
No output, so no retpoline mitigation in Raspbian Buster (reported).

I doubt you could write this off as an academic curiosity or harmless because `there is no malware that uses this attack vector.`.
ARM tells a different story (17-06-2019),see link OP, they explicitly state that an A72 processor is vulnerable, and write about needed mitigation mechanisms.

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2074
Joined: Thu Jul 11, 2013 2:37 pm

Re: RPI4, out of order and Spectre vulnerabilities

Sun Jun 30, 2019 10:54 pm

Aardappeltaart wrote:
Sun Jun 30, 2019 6:24 pm

I doubt you could write this off as an academic curiosity or harmless because `there is no malware that uses this attack vector.`.
ARM tells a different story (17-06-2019),see link OP, they explicitly state that an A72 processor is vulnerable, and write about needed mitigation mechanisms.
Re-read my post. I didn't state that it's currently an academic curiosity on A72 - only when mitigations are applied.
Rockets are loud.
https://astro-pi.org

chwe
Posts: 116
Joined: Tue Jul 31, 2018 1:35 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 12:09 am

jdb wrote:
Sun Jun 30, 2019 10:54 pm
Aardappeltaart wrote:
Sun Jun 30, 2019 6:24 pm

I doubt you could write this off as an academic curiosity or harmless because `there is no malware that uses this attack vector.`.
ARM tells a different story (17-06-2019),see link OP, they explicitly state that an A72 processor is vulnerable, and write about needed mitigation mechanisms.
Re-read my post. I didn't state that it's currently an academic curiosity on A72 - only when mitigations are applied.
Then this should be default? shouldn't it? is it?

lb
Posts: 261
Joined: Sat Jan 28, 2012 8:07 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 1:16 am

jamesh wrote:
Sun Jun 30, 2019 5:32 pm
No, IMO they are not a significant issue, even if the mitigation isn't built in to the kernel or the silicon. because, as above, AIUI there is no malware that uses this attack vector.
Sorry, but that's a really bad argument. With this kind of reasoning, you might as well never pro-actively fix any security bugs - until your systems are compromised. If the CPU cores are affected by significant Spectre variants, mitigations must be applied. I'm not sure why this is even being discussed!

Cortex-A72 is affected by four different Spectre variants. We need some clarity about what hardware mitigations are enabled in the core revision used (if any) and what mitigations are in place in kernel and Raspbian userland.

Heater
Posts: 13106
Joined: Tue Jul 17, 2012 3:02 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 5:02 am

lb,

Normally I would wholeheartedly agree with you.

If we were discussing a "normal" software vulnerability. They are usually simple bugs in some code somewhere. Or some oversight in their logical design. They can be relatively easily fixed with a patch to the appropriate software item(s)

Specter and Meltdown are rather different. There is no logical bug in the processor hardware or in the Linux kernel or in the application software. Nothing that one can point a finger at and can be easily patched.

Those that research this and have been commenting on it say it's very hard to defend against, and requires work that permeates everything.
And that they expect an endless stream of further demonstrations of different styles of exploiting it over the coming years.

For example, read what Linus Torvalds has said about it recently https://devops.com/linus-torvalds-sees- ... hes-ahead/

lb
Posts: 261
Joined: Sat Jan 28, 2012 8:07 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 7:10 am

I don't agree: side-channel attacks are nothing new. What's new is that the bugs are on the hardware level and tricky to fix. However, it is, without significant exceptions, the consensus among OS vendors and CPU manufacturers, that the Spectre bugs are serious and have to be mitigated by default. It is irresponsible to ignore that.

Aardappeltaart
Posts: 46
Joined: Wed Mar 02, 2016 11:32 am

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 8:18 am

jdb wrote:
Sun Jun 30, 2019 10:54 pm
Re-read my post. I didn't state that it's currently an academic curiosity on A72 - only when mitigations are applied.
I did read it. That is why I did a grep on retpoline.

You sounded like if you do a and b (including retpoline) then it is practically solved.

I doubt that, mitigations are mitigations, not fixes.

Furthermore retpoline is not gonna help on ARM according to ARM
Arm has investigated the use of retpoline and has concluded that it doesn't provide effective mitigation on Arm-based systems.
And as the Pi is developed for educational purposes, it does sound like the right computer for academic curiosities, making it even more relevant.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23366
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 8:32 am

Aardappeltaart wrote:
Mon Jul 01, 2019 8:18 am
jdb wrote:
Sun Jun 30, 2019 10:54 pm
Re-read my post. I didn't state that it's currently an academic curiosity on A72 - only when mitigations are applied.
I did read it. That is why I did a grep on retpoline.

You sounded like if you do a and b (including retpoline) then it is practically solved.

I doubt that, mitigations are mitigations, not fixes.

Furthermore retpoline is not gonna help on ARM according to ARM
Arm has investigated the use of retpoline and has concluded that it doesn't provide effective mitigation on Arm-based systems.
And as the Pi is developed for educational purposes, it does sound like the right computer for academic curiosities, making it even more relevant.
Fixes for Fixes/Meltdown require silicon modification, and that I believe impacts heavily on performance. So SW mitigations are what we have available. And those also have a major performance implication.

I suggest that if you are unhappy with the Pi4 and its use of the A72, and are concerned with possible malware that exploits this, then you use earlier models which do not have this issue.

Meanwhile, I'm going to keep using the Pi4 until someone can point me the in the direction of actual malware on the Pi that takes advantage of the vulnerability and can ACTUALLY do bad things. Note, this is my personal opinion and in no way reflects the opinion of Raspberry Pi, which may be different. I do not know what the official stand is on this.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Heater
Posts: 13106
Joined: Tue Jul 17, 2012 3:02 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 9:17 am

lb,
I don't agree: side-channel attacks are nothing new.
True. Side-channel attacks, "covert channels" as GCHQ likes to call them, have been around forver and still are.

A classic example is the fact that one could snoop on the RF emissions of computers monitors and harvest all kinds of information, even when not in the building! For this reason my office when working on sensitive military projects had no windows, no telephone lines or network connections, and had to be located quite some way inside the perimeter fence of the site.

Did anyone ever fix that side channel in monitors? No. Did any one care? Not so many. Did it ever get used as an exploit for real? Probably on some rare occasions.

Point is, it was not a bug in hardware or software. It could not be fixed easily or cheaply. If it was an issue to you then you took your own precautions.

I view Specter and Meltdown in the same light as that remote monitor sniffing. It's not a bug. It's is hard to eliminate. It does not affect anybody yet. It is only a concern if you are running unknown, untrusted code on your machines. For example if you are a cloud hosting service running all kind of code for clients in VMs. Or if you are in the habit of downloading and running all kind of unknown code to your PC, from random web sites.

Also, similarly to the monitor snooping side channel, if it is a concern for you then take responsibility:

1) In the extreme don't use machines that are susceptible to it. Use older Pi for example. Or very old PC's.

2) Don't keep sensitive information on your Pi. Or any PC for that matter.

3) Don't download and run all kind of unknown and untrusted code from God knows where.

4) Disable JS in your browsers and such.
However, it is, without significant exceptions, the consensus among OS vendors and CPU manufacturers, that the Spectre bugs are serious and have to be mitigated by default.
I don't want to imply that Specter and Meltdown are not serious and can be ignored. Far from it.

Not only is it a "consensus among OS vendors and CPU manufacturers" that this is a problem. They are also working very hard to do something about it. That's a lot of people from the chip makers, to the kernel developers, to browser creators and all kind of other things.

Expecting the Pi Foundation to just "Fix it" is as unreasonable as it would have been to expect PC builders to fix the monitor RF emissions side channel back in the day.

In short, take responsibility of your own security. Be aware. Take counter measures in proportion to the threat and the importance of what you are protecting.

LeMoog
Posts: 38
Joined: Thu Jun 18, 2015 1:29 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 11:29 am

Indeed do not poopoo securities vulnerabilities unless of course you are willing to help pay to mitigate the damage done when they are exploited.

I really liked the idea of a desktop replacement PI but for me it would be to replace the known security fail that is the x86.

With a vulnerable PI with it's single hardware base then it is going to be hit harder than even the x86 especially with the emphasis upon IOT and other always on services.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7140
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 11:47 am

/sys/devices/system/cpu/vulnerabilities/ is provided by the kernel config option CONFIG_GENERIC_CPU_VULNERABILITIES.
It is not a user configurable option, and is set automagically for alpha, powerpc, x390, and x86 platforms only. (Why it is not set for ARM is a question for the ARM maintainers, but is not in itself an issue)

The main config option for Spectre mitigation on ARM is CONFIG_CPU_SPECTRE, which then selects CONFIG_HARDEN_BRANCH_PREDICTOR and others. This is enabled on the Pi4 kernel build I've just checked.

Code: Select all

pi@raspberrypi:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y
The arm64 architecture appears not to have any config options directly referencing Spectre.

retpoline is a phrase coined within the x86 architecture

Code: Select all

~/Pi/linux/arch$ grep -R retpoline *
x86/Makefile:  # are subject to retpolines for small number of switch cases.
x86/Makefile:  # retpoline builds, however, gcc does not for x86. This has
x86/Makefile:	@echo "You are building kernel with non-retpoline compiler." >&2
x86/include/asm/nospec-branch.h: * This is required in various cases for retpoline and IBRS-based
x86/include/asm/nospec-branch.h: * This should be used immediately before a retpoline alternative.  It tells
x86/include/asm/nospec-branch.h: * objtool where the retpolines are so that it can make sense of the control
x86/include/asm/nospec-branch.h: * objtool the subsequent indirect jump/call is vouched safe for retpoline
x86/include/asm/nospec-branch.h:	.pushsection .discard.retpoline_safe
x86/include/asm/nospec-branch.h: * These are the bare retpoline primitives for indirect jmp and call.
x86/include/asm/nospec-branch.h:.Ldo_retpoline_jmp_\@:
x86/include/asm/nospec-branch.h:	call	.Ldo_retpoline_jmp_\@
x86/include/asm/nospec-branch.h:	".pushsection .discard.retpoline_safe\n\t"		\
x86/include/asm/nospec-branch.h: * For i386 we use the original ret-equivalent retpoline, because
x86/include/asm/nospec-branch.h:#else /* No retpoline for C / inline asm */
x86/include/asm/nospec-branch.h: * retpoline and IBRS mitigations for Spectre v2 need this; only on future
x86/include/asm/nospec-branch.h: * With retpoline, we must use IBRS to restrict branch prediction
x86/include/asm/nospec-branch.h: * With retpolines configured:
x86/include/asm/nospec-branch.h: * Without retpolines configured:
x86/kernel/cpu/bugs.c:bool retpoline_module_ok(bool has_retpoline)
x86/kernel/cpu/bugs.c:	if (spectre_v2_enabled == SPECTRE_V2_NONE || has_retpoline)
x86/kernel/cpu/bugs.c:	[SPECTRE_V2_RETPOLINE_GENERIC]		= "Mitigation: Full generic retpoline",
x86/kernel/cpu/bugs.c:	[SPECTRE_V2_RETPOLINE_AMD]		= "Mitigation: Full AMD retpoline",
x86/kernel/cpu/bugs.c:	{ "retpoline",		SPECTRE_V2_CMD_RETPOLINE,	  false },
x86/kernel/cpu/bugs.c:	{ "retpoline,amd",	SPECTRE_V2_CMD_RETPOLINE_AMD,	  false },
x86/kernel/cpu/bugs.c:	{ "retpoline,generic",	SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
x86/kernel/cpu/bugs.c:		pr_err("retpoline,amd selected but CPU is not AMD. Switching to AUTO select\n");
x86/kernel/cpu/bugs.c:			goto retpoline_auto;
x86/kernel/cpu/bugs.c:			goto retpoline_amd;
x86/kernel/cpu/bugs.c:			goto retpoline_generic;
x86/kernel/cpu/bugs.c:			goto retpoline_auto;
x86/kernel/cpu/bugs.c:	pr_err("Spectre mitigation: kernel not compiled with retpoline; no mitigation available!");
x86/kernel/cpu/bugs.c:retpoline_auto:
x86/kernel/cpu/bugs.c:	retpoline_amd:
x86/kernel/cpu/bugs.c:			pr_err("Spectre mitigation: LFENCE not serializing, switching to generic retpoline\n");
x86/kernel/cpu/bugs.c:			goto retpoline_generic;
x86/kernel/cpu/bugs.c:	retpoline_generic:
x86/kernel/cpu/bugs.c:	 * the user might select retpoline on the kernel command line and if
x86/lib/Makefile:lib-$(CONFIG_RETPOLINE) += retpoline.o
x86/Kconfig:	  Compile kernel with the retpoline compiler options to guard against
Don't take it as a golden phrase that applies to everything.

Basically the main mitigations within the kernel are in place.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Heater
Posts: 13106
Joined: Tue Jul 17, 2012 3:02 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 12:45 pm

LeMoog,
With a vulnerable PI with it's single hardware base then it is going to be hit harder than even the x86 especially with the emphasis upon IOT and other always on services.
Nonsense.

Firstly are you suggesting that that x86 systems used by MS, Google, Amazon and most other cloud service providers aren't allways on? It's news to me that they turned them off at night :)

Anyone building IoT boxes should not be running any code random code of unkown origin that the device thinks is a good idea to download and run. If it is then there are bigger more easily exploited vulnerabilities in store for it.

Despite the amazing sales of the Pi it's still a drop in the ocean compared to x86 for PCs, laptops, servers. It's a drop in the ocean compared to all the other IoT systems out there.

If you want to forgo the Pi and stay with your far more insecure PC then go ahead.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23366
Joined: Sat Jul 30, 2011 7:41 pm

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 1:17 pm

6by9 wrote:
Mon Jul 01, 2019 11:47 am
/sys/devices/system/cpu/vulnerabilities/ is provided by the kernel config option CONFIG_GENERIC_CPU_VULNERABILITIES.
It is not a user configurable option, and is set automagically for alpha, powerpc, x390, and x86 platforms only. (Why it is not set for ARM is a question for the ARM maintainers, but is not in itself an issue)

The main config option for Spectre mitigation on ARM is CONFIG_CPU_SPECTRE, which then selects CONFIG_HARDEN_BRANCH_PREDICTOR and others. This is enabled on the Pi4 kernel build I've just checked.

Code: Select all

pi@raspberrypi:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y
The arm64 architecture appears not to have any config options directly referencing Spectre.

retpoline is a phrase coined within the x86 architecture

Code: Select all

~/Pi/linux/arch$ grep -R retpoline *
x86/Makefile:  # are subject to retpolines for small number of switch cases.
x86/Makefile:  # retpoline builds, however, gcc does not for x86. This has
x86/Makefile:	@echo "You are building kernel with non-retpoline compiler." >&2
x86/include/asm/nospec-branch.h: * This is required in various cases for retpoline and IBRS-based
x86/include/asm/nospec-branch.h: * This should be used immediately before a retpoline alternative.  It tells
x86/include/asm/nospec-branch.h: * objtool where the retpolines are so that it can make sense of the control
x86/include/asm/nospec-branch.h: * objtool the subsequent indirect jump/call is vouched safe for retpoline
x86/include/asm/nospec-branch.h:	.pushsection .discard.retpoline_safe
x86/include/asm/nospec-branch.h: * These are the bare retpoline primitives for indirect jmp and call.
x86/include/asm/nospec-branch.h:.Ldo_retpoline_jmp_\@:
x86/include/asm/nospec-branch.h:	call	.Ldo_retpoline_jmp_\@
x86/include/asm/nospec-branch.h:	".pushsection .discard.retpoline_safe\n\t"		\
x86/include/asm/nospec-branch.h: * For i386 we use the original ret-equivalent retpoline, because
x86/include/asm/nospec-branch.h:#else /* No retpoline for C / inline asm */
x86/include/asm/nospec-branch.h: * retpoline and IBRS mitigations for Spectre v2 need this; only on future
x86/include/asm/nospec-branch.h: * With retpoline, we must use IBRS to restrict branch prediction
x86/include/asm/nospec-branch.h: * With retpolines configured:
x86/include/asm/nospec-branch.h: * Without retpolines configured:
x86/kernel/cpu/bugs.c:bool retpoline_module_ok(bool has_retpoline)
x86/kernel/cpu/bugs.c:	if (spectre_v2_enabled == SPECTRE_V2_NONE || has_retpoline)
x86/kernel/cpu/bugs.c:	[SPECTRE_V2_RETPOLINE_GENERIC]		= "Mitigation: Full generic retpoline",
x86/kernel/cpu/bugs.c:	[SPECTRE_V2_RETPOLINE_AMD]		= "Mitigation: Full AMD retpoline",
x86/kernel/cpu/bugs.c:	{ "retpoline",		SPECTRE_V2_CMD_RETPOLINE,	  false },
x86/kernel/cpu/bugs.c:	{ "retpoline,amd",	SPECTRE_V2_CMD_RETPOLINE_AMD,	  false },
x86/kernel/cpu/bugs.c:	{ "retpoline,generic",	SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
x86/kernel/cpu/bugs.c:		pr_err("retpoline,amd selected but CPU is not AMD. Switching to AUTO select\n");
x86/kernel/cpu/bugs.c:			goto retpoline_auto;
x86/kernel/cpu/bugs.c:			goto retpoline_amd;
x86/kernel/cpu/bugs.c:			goto retpoline_generic;
x86/kernel/cpu/bugs.c:			goto retpoline_auto;
x86/kernel/cpu/bugs.c:	pr_err("Spectre mitigation: kernel not compiled with retpoline; no mitigation available!");
x86/kernel/cpu/bugs.c:retpoline_auto:
x86/kernel/cpu/bugs.c:	retpoline_amd:
x86/kernel/cpu/bugs.c:			pr_err("Spectre mitigation: LFENCE not serializing, switching to generic retpoline\n");
x86/kernel/cpu/bugs.c:			goto retpoline_generic;
x86/kernel/cpu/bugs.c:	retpoline_generic:
x86/kernel/cpu/bugs.c:	 * the user might select retpoline on the kernel command line and if
x86/lib/Makefile:lib-$(CONFIG_RETPOLINE) += retpoline.o
x86/Kconfig:	  Compile kernel with the retpoline compiler options to guard against
Don't take it as a golden phrase that applies to everything.

Basically the main mitigations within the kernel are in place.
You may need to `sudo modprobe configs` to get the proc entry.

I wonder if turning this off will improve performance?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
bensimmo
Posts: 4156
Joined: Sun Dec 28, 2014 3:02 pm
Location: East Yorkshire

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 1:30 pm

Heater wrote:
Mon Jul 01, 2019 12:45 pm
LeMoog,
With a vulnerable PI with it's single hardware base then it is going to be hit harder than even the x86 especially with the emphasis upon IOT and other always on services.
Nonsense.

Firstly are you suggesting that that x86 systems used by MS, Google, Amazon and most other cloud service providers aren't allways on? It's news to me that they turned them off at night :)

Anyone building IoT boxes should not be running any code random code of unkown origin that the device thinks is a good idea to download and run. If it is then there are bigger more easily exploited vulnerabilities in store for it.

Despite the amazing sales of the Pi it's still a drop in the ocean compared to x86 for PCs, laptops, servers. It's a drop in the ocean compared to all the other IoT systems out there.

If you want to forgo the Pi and stay with your far more insecure PC then go ahead.
It's a drop in the ocean compared to these portable computer things I'm holding in my hand typing this on.
Which I believe is Linux right at the bottom of it all.
I'm assuming there are a couple of them around, and some powerful one must use the same processor, lucky for me mine only has 8 of the lowly A53

Aardappeltaart
Posts: 46
Joined: Wed Mar 02, 2016 11:32 am

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 2:41 pm

6by9 wrote:
Mon Jul 01, 2019 11:47 am

Code: Select all

pi@raspberrypi:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y
Basically the main mitigations within the kernel are in place.
Thx 6by9. That is useful info.

Interestingly mitigations are also in place at my RPI2, which is not vulnerable at all.

Code: Select all

pi@pi2:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y

Which makes jamesh question relevant:
Will turning this off improve performance?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7140
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 4:06 pm

Aardappeltaart wrote:
Mon Jul 01, 2019 2:41 pm
6by9 wrote:
Mon Jul 01, 2019 11:47 am

Code: Select all

pi@raspberrypi:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y
Basically the main mitigations within the kernel are in place.
Thx 6by9. That is useful info.

Interestingly mitigations are also in place at my RPI2, which is not vulnerable at all.

Code: Select all

pi@pi2:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y

Which makes jamesh question relevant:
Will turning this off improve performance?
Support for the mitigations is built in.
My recollection of all the x86 mitigations is that they can all be disabled from the Linux command line, so I wouldn't be surprised if they were automatically disabled should the processor not need them. I'm not going to investigate them further.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Aardappeltaart
Posts: 46
Joined: Wed Mar 02, 2016 11:32 am

Re: RPI4, out of order and Spectre vulnerabilities

Mon Jul 01, 2019 5:25 pm

6by9 wrote:
Mon Jul 01, 2019 4:06 pm
Aardappeltaart wrote:
Mon Jul 01, 2019 2:41 pm
6by9 wrote:
Mon Jul 01, 2019 11:47 am

Code: Select all

pi@raspberrypi:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y
Basically the main mitigations within the kernel are in place.
Thx 6by9. That is useful info.

Interestingly mitigations are also in place at my RPI2, which is not vulnerable at all.

Code: Select all

pi@pi2:~ $ zcat /proc/config.gz | grep SPECTRE
CONFIG_CPU_SPECTRE=y

Which makes jamesh question relevant:
Will turning this off improve performance?
Support for the mitigations is built in.
My recollection of all the x86 mitigations is that they can all be disabled from the Linux command line, so I wouldn't be surprised if they were automatically disabled should the processor not need them. I'm not going to investigate them further.
Yes, I think you're right. In Linux (>5.2) it's something like adding to grub ` mitigations=off ` or `pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable` on older kernels, while the default is `mitigations=auto`, so I guess adding that to `/boot/cmdline.txt` might work.

I was just surprised to see it enabled in Stretch, but `auto` does make sense.

Return to “General discussion”