CPU SMT vulnerability mitigation

Usually, if you are susceptible to the SMT CPU vulnerability, the Linux kernel will automatically apply mitigations, but will not disable SMT, which would be equivalent to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=auto"

mitigations=auto is the default, so it's not usually included in that line.

If you're susceptible to the SMT CPU vulnerability, and you're paranoid about data exfiltration, you can disable SMT.

Open gedit as root:
sudo gedit

In gedit, open the file:


GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=auto,nosmt"

Save the file and exit gedit, then issue:
sudo update-grub

sudo reboot

Then inspect the applied CPU vulnerability mitigations:
sudo lscpu

You will note that if you've got what Windows calls Hyper-Threading and a 4 core CPU, that 4 of your CPUs are now offline, and 4 are online.

I'm not sure if that means that half of your processor is now unusable, or if the system is now using the 4 cores as if they're full CPUs and it doesn't matter that those 4 CPUs are offline. Anyone know?


The threads run as a single thread i believe not a multi thread, however it still run multiple process. You probably won't see any impact unless you are running a thread intensive workload. Ryzen and newer INtel cpus are less affected than older intel cpus for performance hits with mitigation btw.

So basically, the processor will handle half as many threads simultaneously as it did before SMT was disabled, but each thread has twice as many transistors processing on it?

So the full processor is still being used with SMT disabled?

Whelp, disabling SMT is not going to work for my 2012-era CPU (Intel Core i7-2670QM)... push the machine a bit, and the cursor gets jerky, everything slows way down and the machine becomes essentially unusable.

I bet this thing would fly if I set:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mitigations=off"
... but I'm not going to. It's plenty fast as is, and I'm not a gamer, so I don't need more speed.

1 Like