“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.

The line

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.

Kernel parameters

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:

  • nopti
    Control Page Table Isolation of user and kernel address spaces.  Disabling this feature removes hardening, but improves performance of system calls and interrupts.
  • no_stf_barrier
    Parameter is not documented.
  • tsx=on
    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.
  • mitigations=off
    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.