“Make linux fast again” for mortals
I want my systems to be fast. Fast is good. Fast is more time for executing the tasks that create value. Of course you want that too. I want to help you with that. Promise.
I recently stumbled upon Make linux fast again which contains one and only line of text and nothing else. And it is a interesting one. But, the line is by no means easy to understand. Let’s break it down together.
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
This minimalistic page, believe it or not, does create quite a lot of fuzz, for example see the related thread in Hacker News. But what does the text mean? How to use it? If it so good that there is a dedicated page, why is it not activated be default? These and a lot more questions popped up in my head. Since I am probably not alone having these questions after opening one of the most minimalistic pages, I thought we could give it a try to decode the hidden messages into something readable for people that might not be Linux kernel hackers.
Before we start, a disclaimer, as we will see there are good reasons why some of these parameters are not set by default.
The list of what at first glace might look like random words and letters are actually parameters, more specifically “linux kernel command-line parameters” or just “kernel parameters”. Most of them can be found in the official linux kernel documentation, but interestingly not all are even documented, but let’s break down the descriptions of the different parameters:
noibrsTurns off Indirect Branch Restricted Speculation (IBRS), related to the Spectre vulnerability.
Control Page Table Isolation of user and kernel address spaces. Disabling this feature removes hardening, but improves performance of system calls and interrupts.
Disable all mitigations for the Spectre variant 2 (indirect branch prediction) vulnerability. System may allow data leaks with this option.
Disable mitigations for Spectre Variant 1 (bounds check bypass). With this option data leaks are possible in the system.
Control mitigation of the L1TF vulnerability on affected CPUs.
Disable all mitigations for the Speculative Store Bypass vulnerability.
Parameter is not documented.
Control mitigation for the Micro-architectural Data Sampling (MDS) vulnerability.
Control Transactional Synchronization Extensions (TSX) feature in Intel processors that support TSX control. Although there are mitigations for all known security vulnerabilities, TSX has been known to be an accelerator for several previous speculation-related CVEs, and so there may be unknown security risks associated with leaving it enabled.
Control mitigation for the TSX Async Abort (TAA) vulnerability.
Disable all optional CPU mitigations. This improves system performance, but it may also expose users to several CPU vulnerabilities.
So, setting these kernel parameters will give the system a performance boost, but will also disabled a lot of mitigations and expose your system for security vulnerabilities such as Meltdown and Spectre.
Apply kernel parameters from bootloaders
Even if the mentioned kernel parameters cannot be recommended, it might be interesting to know how to apply these or any other kernel parameter. Kernel parameters can be set in a couple of different ways, but most straight forward way to set the parameter is probably via the bootloader. Simplified the bootloader is an application which is started early during the boot process and among other tasks handles the start of the kernel.
Unless the linux system is an embedded device, the bootloader is most likely GRUB. For example, for Ubuntu the config file is found at
/etc/default/grub, add the wanted parameters to the line starting with
GRUB_CMDLINE_LINUX_DEFAULT. Save the changes and update GRUB with
update-grub, then reboot the system to activate the changes. More details about how to do this and also how to add temporary kernel parameters can be found in the documentation for Ubuntu.
For more specialized devices, such as embedded devices, the choice of bootloader depends on for example how much flexibility is required at boot. One popular choice of bootloader is U-Boot. U-Boot passes kernel parameters via the
bootargs environment variable, for example
setenv bootargs root=/dev/ram rw as describe in the U-Boot documentation.
Hopefully this article could clarify some of the cryptic parameters, give an insight to the documentation for kernel parameters and give the basic knowledge how the parameters could be applied.