Linux kernel gets another option to disable Spectre mitigations
Believe it or not, the mitigations for the Spectre-class of CPU vulnerabilities are now some of the biggest enemies of system administrators.
Despite being security-focused patches, these mitigations are known to introduce huge performance hits to Linux systems.
A recent benchmark showed that just one of the many Spectre mitigations –namely the one named Single Thread Indirect Branch Predictors (STIBP)– introduced a 30 percent performance dip for PHP servers, causing system administrators to reconsider applying some of these patches.
Despite being more than one year old, the Meltdown or Spectre vulnerabilities have remained a theoretical threat, and no malware strain or threat actor has ever used any in a real-world attack.
Over the course of the last year, system and network administrators have called on the Linux project for options to disable these protections.
Many argued that the threat is theoretical and could easily be mitigated with proper perimeter defenses, in some scenarios. Even Linus Torvalds has called for a slowdown in the deployment of some performance-hitting Spectre mitigations.
The Linux kernel team has reacted positively towards these requests and has been slowly adding controls to disable some of the more problematic mitigations.
For example, since Linux Kernel 4.15, administrators can disable the kernel’s built-in mitigations for the Spectre v2 vulnerability (CVE-2017-5715) with the “nospectre_v2” kernel command line parameter.
Since Linux Kernel 4.17, administrators can disable all mitigations for Spectre v4 (CVE-2018-3639) with the “nospec_store_bypass_disable” command line parameter.
Similarly, a way to disable mitigations for Spectre v1 (CVE-2017-5753) has been added in the Linux Kernel 4.19, with the addition of the “nospectre_v1” parameter.
These three parameters were added despite the kernel already featuring the “spectre_v2” and “spec_store_bypass_disable” options for months, parameters that let system administrators control the complexity level of the Spectre-class mitigations, options which also included an “off” mode.
System administrators wanted a way to make sure that Spectre mitigations wouldn’t kick in, at all, hence, the three new parameters in recent kernel releases.
The latest effort to have mitigations turned off –and stay down– is the addition of the PR_SPEC_DISABLE_NOEXEC control bit to the Linux kernel.
This bit will prevent child processes from starting in a state where the protections for Spectre v4 are still activated, despite being deactivated in the parent process.
Experts argue that some processes just don’t need Spectre protections and the performance impact far outweighs the security impact, especially in closed systems where malicious code can’t be introduced, such as graphics rendering farms, off-the-grid supercomputers, and other strictly confined systems where no third-party code is ever run.
As time will pass, more of these controls will end up being added to the Linux kernel, as the Linux ecosystem draws a fine line between protection and performance, allowing server owners to choose the side they’d like to be on.
But if you’re one of those who prefers security, the US National Security Agency has recently updated its all-in-one guidance page for all the recent Spectre-like CPU vulnerabilities. It’s a good place to catch up on your knowledge about these flaws and take the first steps to mitigated them.
Related security coverage:
READ MORE HERE