A Global Switch To Kill Linux's CPU Spectre/Meltdown Workarounds?

[flower]

"pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"

Does it disable ALL the mitigations or some of them cannot be simply disabled?

the microcode mitigations are not disabled. only way i know is to stay below version 22 - which is probably not a good idea

[perpetually high]

How come `noretpoline` didn't make the list? Is it implicitly included in one of the other ones?

If I'm not mistaken, retpoline is a mitigation strategy for spectre v2, so when you spectre_v2=off, you're essentially saying you know what, just disable any and all spectre v2 mitigations.

To check if you're currently using retpoline, type:

$ dmesg | grep 'retpoline'

If the above returns nothing, then no retpoline, but not necessarily not spectre v2 mitigation (done through microcode and kernel I believe)

"pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"

Does it disable ALL the mitigations or some of them cannot be simply disabled?

It disables all of them except spectre v1, which I believe is baked in to software/compiler/kernel.

On my machine, it shows:

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

$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled
Vulnerable
Vulnerable
Mitigation: __user pointer sanitization
Vulnerable

and I have the boot parameters set in /etc/default/grub of:

GRUB_CMDLINE_LINUX_DEFAULT="quiet pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"

If I check my init process, I can see it take effect:

$ ps aux | grep init
root 1 0.0 0.0 217960 9648 ? Ss Aug24 0:04 /sbin/init nospec_store_bypass_disable no_stf_barrier

To check if PTI is disabled, I can do:

$ dmesg | grep 'page tables isolation'
[ 0.000000] Kernel/User page tables isolation: disabled on command line.

Lastly, a more in depth scan can be done with spectre meltdown checker. Be sure to enable Strict Site Isolation in your browsers if you're going to disable these mitigations.

the microcode mitigations are not disabled. only way i know is to stay below version 22 - which is probably not a good idea

I assume you're talking about Haswell? If so, that's true. I'm using 22 right now. 23 was the first with spectre mitigations, 25 is the latest with l1tf. Users of newer systems don't have the luxury since they should probably use the latest microcodes for any other fixes/improvements.

[fguerraz]

One can also add 'kvm-intel.vmentry_l1d_flush=never' if you run VMS and don't care too much about isolation and want your performance back.

[DarkFoss]

Atleast with linux you have the options to disable unlike Win 10. I just had KB4100347 install on my AMD system and with the latest Windows there is no longer an option to hide it.
So now ever time I update windows I will have to manually uninstall this "fix" . As Steam Play matures my needs to boot to Windows will diminish alot

[numacross]

"pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"

Does it disable ALL the mitigations or some of them cannot be simply disabled?

There are compiler-level mitigations as well for both GCC and LLVM.

[Ehvis]

Of course, that's not recommended unless you really trust the code running on your system and the overall system security.

If that's not the case, then the problem you have is probably a lot bigger than whatever spectre/meltdown can add to it. So far I have seen no compelling reason why a home user or gamer would be affected by spectre/meltdown at all.

[werpu]

Soon new CPUs are coming that is expected to have in-silicon mitigations for the Meltdown and Spectre hardware vulnerabilities.
Such as the upcoming Intel "Ice Lake" CPU.
Maybe also upcoming Ryzen.

If you are on an AMD system atm you wont need such a kill switch, the performance impacts of the few fixes amd needed to issue are basically zero.
I dont expect that the 2019 7nm ryzens will have the fixes in, this is still the Ryzen architecture just on 7nm, but I can be wrong, either way, the bugs and their performance impact are mostly a non issue on the AMD side.

[cybertraveler]

If that's not the case, then the problem you have is probably a lot bigger than whatever spectre/meltdown can add to it. So far I have seen no compelling reason why a home user or gamer would be affected by spectre/meltdown at all.

Typical home users and gamers should absolutely not disable these spectre and meltdown mitigations. Without them a custom map for a game, a website running javascript or malicious code running in a virtual machine could either take control of the system or gain access to sensitive data.

This is not to even mention that meltdown can enable privilege escalation. This means that a user process or even a security sandboxed user process which is compromised by an attacker could gain access to kernel memory.

The vast majority of computer users should leave all these mitigations enabled.

Edit: Removed my comment that meltdown could also be used to "gain full control over the PC". I was mistaken about this: it might be achievable with some systems, but it's not a given that this can be done.

[markg85]

For now the closest way to making an unmitigated kernel for not losing out on CPU performance would be booting the kernel with pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier. Of course, that's not recommended unless you really trust the code running on your system and the overall system security.

all those patches only make sense in environments where you could have other users on the same cpu. So that would be cloud environment, a hosting provider, ... So the googles and amazons of this world are indeed better off applying those.

For any local linux desktop use these patches are total bullshit.
As a user you would only be very VERY VERY marginally more insecure by not having those patches. There are far easier ways to hack a user then to go though cpu bugs.

I stopped considering these patches as "sane" since the latest L1TF ones where disabling hyper-threading was a solution (thus crippling your performance). We basically get thrown back years in performance if we start applying those suggestion. This is just security paranoia that makes no sense at all anymore.

And i'm not being sarcastic here. I'm dead serious.

[F.Ultra]

all those patches only make sense in environments where you could have other users on the same cpu. So that would be cloud environment, a hosting provider, ... So the googles and amazons of this world are indeed better off applying those.

For any local linux desktop use these patches are total bullshit.
As a user you would only be very VERY VERY marginally more insecure by not having those patches. There are far easier ways to hack a user then to go though cpu bugs.

I stopped considering these patches as "sane" since the latest L1TF ones where disabling hyper-threading was a solution (thus crippling your performance). We basically get thrown back years in performance if we start applying those suggestion. This is just security paranoia that makes no sense at all anymore.

And i'm not being sarcastic here. I'm dead serious.

Well that works I guess until you discover just how many mods your kids are using in Terraria/Minecraft/whatever at which point you realise just how much untrusted code that really runs on your system.