Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 18+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium.
Improved Spectre/Meltdown Switches Might Finally Come To The Linux Kernel
It's been possible from the start to disable most of these mitigations at run-time (sans like __user pointer sanitization for Spectre V1) but the kernel command line parameters to use haven't been the most straight-forward or easy to remember... There hasn't been a global switch to kill Spectre/Meltdown mitigations in one easy-to-add option. At this stage to disable the mitigations on most patched Linux kernel releases it comes down to having to remember and add "pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable." Similarly, if wanting to beef-up the security even more of the system with the "maximum mitigations" there are the "l1tf=full spec_store_bypass_disable=on spectre_v2_user=on" for better securing the system against these vulnerabilities but also hitting the performance even more severely due to HT/SMT being disabled among other measures.
Red Hat developer Josh Poimboeuf has reignited the upstream discussion over offering up some simpler command-line tunables for disabling these CPU speculation mitigations or driving up the protection, rather than having to remember all these multiple options. Poimboeuf's initial proposal came down to a cpu_spec_mitigations= kernel option with values of off/auto/nosmt.
There has been some resistance to the "cpu_spec_mitigations=" name itself as it's a bit long, but nothing conclusive has been decided for a shorter and better to remember string besides maybe just "spec_mitigations=" instead. The proposed patches cover just not x86_64 but also CPU spec vulnerabilities affecting ARM, s390, etc.
The work for now is still being discussed on the kernel mailing list and we'll see what comes of this work, stay tuned.