You probably have heard about Meltdown and Spectre vulnerabilities that affected many modern processors, including certain processors by Intel, AMD, System Z, Power and ARM. Thankfully, the Kernel developers have released security patches to address the Meltdown/Spectre issues. In the recent Kernel versions, the patches are implemented by default. Even though the security patches helps to mitigate the vulnerabilities, they also have impacted the system's performance as well. Yes, the mitigations will cause a performance hit. If you are confident that your systems are well-protected and want every ounce of performance that you can get out of your personal system, this guide is for you. This brief guide explains how to make Linux system to run faster on Intel CPUs by turning off the Spectre and Meltdown mitigations.
A word of caution
Before implementing the following solution, I must warn you - THIS IS HIGHLY INSECURE and NOT RECOMMENDED. This will disable all Spectre and Meltdown mitigations on Intel CPUs and leave your Linux systems wide open to all security risks. Unless you clearly know what you are doing, don't do this. You have been warned!
If you simply don't care about the security, go ahead and disable the mitigations as described below.
Make Linux System To Run Faster On Intel CPUs
Edit your GRUB file using your preferred text editor.
On Debian, Ubuntu:
$ sudo nano /etc/default/grub
If you're using Linux Kernel version 5.1.13 and newer, add/edit the following Kernel parameter like below:
This will disable all optional CPU mitigations. This improves system performance, but it may also expose users to several CPU vulnerabilities.
If you're using Kernel versions older than 5.1.13, add/edit the following instead:
GRUB_CMDLINE_LINUX="noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off"
These are the Kernel parameters that you can use for disabling all the Spectre/Meltdown mitigations that are slowing down your Linux system.
Know what each flag does:
- noibrs - Disable Indirect Branch Restricted Speculation in the microcode.
- noibpb - Disable Indirect Branch Prediction Barriers.
- nopti - It is same as pti=off. Control Page Table Isolation of user and kernel address spaces. Disabling this feature removes hardening, but improves performance of system calls and interrupts.
- nospectre_v2 - Disable all mitigations for the Spectre variant 2 (indirect branch prediction) vulnerability. System may allow data leaks with this option, which is equivalent to spectre_v2=off.
- nospectre_v1 - Disable mitigations for Spectre Variant 1 (bounds check bypass). With this option data leaks are possible in the system.
- l1tf=off - Control mitigation of the L1TF vulnerability on affected CPUs. The kernel PTE inversion protection is unconditionally enabled and cannot be disabled. Disables hypervisor mitigations and doesn't emit any warnings. It also drops the swap size and available RAM limit restriction on both hypervisor and bare metal.
- nospec_store_bypass_disable - Disable all mitigations for the Speculative Store Bypass vulnerability.
- no_stf_barrier - Disable Store-forwarding barrier (PPC only).
- mds=off - Control mitigation for the Micro-architectural Data Sampling (MDS) vulnerability.
- tsx=on - Enable Intel's TSX (Transactional Synchronization Extensions) support.
- tsx_async_abort=off - Disable TAA (TSX Async Abort) mitigation.
- mitigations=off - Disable all mitigations.
For more details about each flag, do a quick google search.
After adding the Kernel parameter(s), update the GRUB configuration using command:
$ sudo update-grub
Finally, reboot the system:
$ sudo reboot
On RPM-based systems like CentOS and RHEL, edit /etc/sysconfig/grub file:
$ sudo /etc/sysconfig/grub
Add the above parameters in GRUB_CMDLINE_LINUX. And then update GRUB configuration using command:
$ sudo grub2-mkconfig
$ sudo reboot
In some Linux systems, you might need to add these Kernel parameters in "GRUB_CMDLINE_LINUX_DEFAULT="...".
We have now disabled all Spectre and Meltdown mitigations. This will boost your system's performance a little bit, but it may also expose users to several CPU vulnerabilities.
Check if Spectre/Meltdown mitigations are disabled
We can use "spectre-meltdown-checker" tool that helps you to identify the Spectre and Meltdown vulnerabilities in Linux. It is available in the official repositories of some Linux distributions.
On Debian, Ubuntu:
$ sudo apt install spectre-meltdown-checker
On CentOS, RHEL:
$ sudo yum install epel-release
$ sudo yum install spectre-meltdown-checker
$ sudo dnf install $ sudo apt install spectre-meltdown-checker
After installing spectre-meltdown-checker, run it as root user or with sudo privileges to check if Spectre and Meltdown mitigations are turnd off:
You should see a message something like below.
[...] > STATUS: VULNERABLE (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers) [...] > STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability) [...] > STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)
Alternatively, you can check Spectre/Meltdown vulnerabilities like below.
$ ls /sys/devices/system/cpu/vulnerabilities/
itlb_multihit l1tf mds meltdown spec_store_bypass spectre_v1 spectre_v2 tsx_async_abort
$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:KVM: Vulnerable /sys/devices/system/cpu/vulnerabilities/l1tf:Mitigation: PTE Inversion /sys/devices/system/cpu/vulnerabilities/mds:Vulnerable; SMT Host state unknown /sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers /sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable, STIBP: disabled /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected
Run some benchmarks, and check how much performance you will gain, and then decide whether it's worth to disable everything.
As I have already warned, this tip is a useful and sensible option for home or single-user computers. But not recommended for production systems.