While most users frown upon the increasing number of CPU security mitigations in part due to the additional overhead commonly introduced, a new Linux kernel patch by a Google engineer would allow users/developers to opt-in to forcing CPU bugs and their mitigations even if the system in use isn’t known to be vulnerable.
Google engineer Brendan Jackman posted the patch today for introducing the Linux “force_cpu_bug=” command-line boot parameter for being able to force additional CPU security mitigations even if the processor indicates it’s not vulnerable to a given bug like Spectre, Meltdown, Retbleed, and others.
With this patch, you can boot say “force_cpu_bug=spectre_v1,spectre_v2,spec_store_bypass” if wanting to force the various Spectre mitigations even when not needed. The force_cpu_bug= value is based on the various strings within the “bugs” line of /proc/cpuinfo.
As for why you would want to force a CPU bug mitigation even if not necessary, it can be useful for kernel developers when trying to debug an issue in the code. Or it can also be useful for security researchers in exploring the mitigation impact or operating differences. This force_cpu_bug could also be useful in the future if it’s found that some existing processors aren’t actually immune to a given vulnerability and rather than waiting on a kernel patch or BIOS/microcode update in production, this would allow quickly and easily forcing a given mitigation.
Brendan Jackman of Google summed it up in the force_cpu_bug patch as:
“Sometimes it can be very useful to run CPU vulnerability mitigations on systems where they aren’t known to mitigate any real-world vulnerabilities. This can be handy for mundane reasons like “I wanna debug this on the machine that quickly”, but also for research reasons: while some mitigations are focussed on individual vulns and uarches, others are fairly general, and it’s strategically useful to have an idea how they’d perform on systems where we don’t currently need them.
As evidence for this being useful, a flag specifically for Retbleed was added in commit 5c9a92dec323 (“x86/bugs: Add retbleed=force”).
It’s a bit unfortunate that we have to do this by bug instead of by mitigation. However, we don’t have clear identifiers for the mitigations that we do, so I don’t think it’s practical to do better here than “you can pretend you’re on a vulnerable CPU – now go and read the docs for the per-vuln cmdline params to figure out how to run the mitigation you want”.”
Now for this patch to go through the typical Linux kernel review process while other upstream stakeholders determine if it works well enough and practical for mainlining.
