HOWTO make Linux run blazing fast (again) on Intel CPUs

From LinuxReviews
Jump to navigationJump to search
Zombieload.svg

It's just been one security disaster after another for Intel the last few years. Meltdown, Spectre variant after variant and this week the "Microarchitectural Data Sampling" aka Zombieload attack have all required performance-degrading fixes and workarounds. There is no way around turning hyperthreading off to be safe from MDS/Zombieload and this is a rather high performance-price to pay. So what if you don't want to?

Disabling SMT/HyperThreading to get full protection against MDS/Zombieload on top of the mitigation code for "meltdown", several "spectre" variants and other security-issues discovered on Intel CPUs is a high price to pay for security on Intel CPUs. The total performance-penalty in many workloads is adding up. Unfortunately there is no safe and secure way around the performance-penalties - so you may want to..

TAKE THE RISK?

If you're not into currency trading or high finance or military contracting or anything of that nature and you'd just like to get maximum performance for your Steam games then adding this is simple switch to your kernel parameters will leave you wide open to all the security risks for maximum excitement and squeeze back every bit of performance you used to get from your Intel CPU:

mitigations=off

If you are using a kernel older than 5.1.13 then you should use this rather long one-liner instead:

noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off

Add either mitigations=off or that long one-liner to your /etc/sysconfig/grub and re-generate grub's configuration file with grub2-mkconfig (your distributions procedure will vary) and you're all set. Do note that the latest editions of stable branch kernels (4.14.x, 4.19.x) do have a mitigations= parameter so that alone is enough on kernels newer than 5.1.13 and later versions of stable branch kernels such as 4.19.60+.

Debian/Ubuntu derived distributions: edit the file /etc/default/grub then run the commands update-grub followed by grub-install /dev/sdX where "X" is replaced by the relevant OS drive, usually "a" as in "/dev/sda".

Here is what the above kernel command options did in earlier kernels, one by one:

  • noibrs - We don't need no restricted indirect branch speculation
  • noibpb - We don't need no indirect branch prediction barrier either
  • nospectre_v1 and nospectre_v2: Don't care if some program can get data from some other program when it shouldn't
  • l1tf=off - Why would we be flushing the L1 cache, we might need that data. So what if anyone can get at it.
  • nospec_store_bypass_disable - Of course we want to use, not bypass, the stored data
  • no_stf_barrier - We don't need no barriers between software, they could be friends
  • mds=off - Zombieload attacks are fine
  • mitigations=off - Of course we don't want no mitigations

You are (probably) an adult. You can and should wisely decide just how much risk you are willing to take. Do or don't try this at home. You do not want to try this at work.

Kemonomimi rabbit.svg
Note: The parameters covered by mitigations=off vary by kernel versions. The above switches were applicable prior to kernel 5.1.13 and while they are useful for kernels released prior to the mitigations=off switch they are not current.

You can look at the file Documentation/admin-guide/kernel-parameters.txt in the kernel source for the kernel you are using to see what parameters are actually available on the kernel you are using.

Security parameters covered by mitigations=off in newer kernels

Intel CPUs are not alone in having some security issues. There are problems with other CPUs too. The mitigations=off can be used on any CPU but what it does, if anything, will depend on what CPU you are using. It can be used to slightly increase performance on Intel, AMD, ARM and even PowerPC architectures.

The security parameters covered by mitigations=off in kernel 5.3.6 are:

  • nopti [X86,PPC] - Control Page Table Isolation of user and kernel address spaces. Disabling this feature removes hardening, but improves performance of system calls and interrupts.
  • kpti=0 [ARM64] - Control page table isolation of user and kernel address spaces.
  • nobp=0 [S390] - Undocumented. Does something on S390 systems, nobody knows what.
  • nospectre_v1 [X86,PPC] - Disable mitigations for Spectre Variant 1 (bounds check bypass). With this option data leaks are possible in the system.
  • nospectre_v2 [X86,PPC,S390,ARM64] - Disable all mitigations for the Spectre variant 2 (indirect branch prediction) vulnerability. System may allow data leaks with this option.
  • spectre_v2_user=off [X86] - Control mitigation of Spectre variant 2 (indirect branch speculation) vulnerability between user space tasks
  • spec_store_bypass_disable=off [X86,PPC] - Control Speculative Store Bypass (SSB) Disable mitigation (Speculative Store Bypass vulnerability)
  • ssbd=force-off [ARM64] - Speculative Store Bypass Disable control
  • l1tf=off [X86] - Control mitigation of the L1TF vulnerability on affected CPUs
  • mds=off [X86] - Control mitigation for the Micro-architectural Data Sampling (MDS) vulnerability.

Performance implications

The performance gained by disabling workarounds for the mostly Intel CPU security flaws are not all that impressive in all workloads. The reason is that the most performance-hampering measure required to safely use a Intel CPU is to disable SMT (HyperThreading). Doing so crushes performance in a really noticeable way, so much so that the Linux kernel developers decided to leave SMT enabled by default (unlike some *BSD variants who do disable SMT). Newer Linux kernels will by default use mds=full and not the safer mds=full,nosmt parameter which banks and financial institutions should be using. There is a difference between default performance and performance with mitigations=off but it is nowhere near as large as the difference between mitigations=off and mds=full,nosmt.

6800K-8700K-vs-Intel-CPU-bugs-timed-kernel-compliation.png

6800K-8700K-vs-Intel-CPU-bugs-XZ-compression.png

As the above charts show: The effect of default parameters vs mitigations=off is measurable but not hugely impressive. The effect of disabling SMT, which is required to safely use Intel CPUs, is really noticeable and very measurable. It is required to be sure Intel CPU bugs can not be exploited but the price is high. Choose wisely.


published 2019-05-17last edited 2019-11-17


avatar

Anonymous user #1

6 months ago
Score 2++
Security doesn't matter
avatar

Anonymous user #1

6 months ago
Score 1++
"They could be friends" :D
avatar

Anonymous user #2

6 months ago
Score 1++
Hey guys, it's me, your pal Intel. We make blazing fast CPUs. You don't need security anyway. Disable them all. If anything goes wrong just buy another Intel CPU. We promise we will fix all security holes.
avatar

Anonymous user #2

6 months ago
Score 1++
Highly insecure, but it resulted in a visible change of Ubuntu 18.10. performance using Kernel 5.1. It works snappy now, whereas before the system had to "processsssss" every command. Good or bad - at least now you can jump off the cliff in a Ferrari and not be fcdek up in a Yugo anyway.
avatar

Anonymous user #1

2 months ago
Score 1++
Actually mitigations=off is enough for disable all patches
avatar

Anonymous user #1

2 months ago
Score 0++
Well true but not as funny :D
avatar

Anonymous user #2

one month ago
Score 0++
Need a performance benchmark.
avatar

Anonymous user #2

one month ago
Score 1++
Or... You could buy an AMD CPU
avatar

Anonymous user #3

one month ago
Score -1++
And you can cut your junk off with a dull knife, no thanks.
avatar

Anonymous user #3

one month ago
Score 0++
Sounds like it's time to mine some bitcoins.
avatar

Anonymous user #3

one month ago
Score 0++
but most are shitcoins in fact
avatar

Anonymous user #3

one month ago
Score 0++
"cut your junk off with a dull knife" ? for some gnome users, that'll hardly make a difference , lawl
avatar

Anonymous user #4

one month ago
Score 0++

One note on running mitigations=off ...

If I was running VPS (virtual private server) either via VMs or linux containers (essentially a fancy chroot jail), I would absolutely leave mitigations on. People are running "untrusted" executables on there and a bad actor could easily access other VMs or jails that they should not be able to.

If you're running javascript stuff, it was shown these attacks "could" be run from javascript, BUT all the recent browsers have removed accurate timers, several are like 0.2ms maximum accuracy and a few are 1ms and some jitter too. These attacks rely on high accuracy timers, without that they simply don't work. So no worries about browser based attacks.

Have a good one!

- Henry
avatar

Anonymous user #4

one month ago
Score 1++
Have already moved all my own work to ARM systems. Eagerly waiting RISC-V commercially viable and competitive hardware.
avatar

Vvv

one month ago
Score 0++
yeah totally me too! free hardware forever! cut the yankee crap from Cali
Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.