Improved Spectre/Meltdown Switches Might Finally Come To The Linux Kernel

By the time the next Linux kernel is released it will have been roughly a year and a half since the Spectre and Meltdown CPU speculative execution vulnerabilities went public and the mitigations started appearing within the kernel. Finally now it's being discussed again by upstream developers over improving the switches / tunable knobs for easily configuring these performance-degrading mitigations.

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.