Linux Looks To Change The Default For Some Of Its Spectre Mitigations

Written by Michael Larabel in Linux Security on 5 November 2020 at 04:55 AM EST. 12 Comments
Upstream Linux kernel developers are looking at changing some of their Spectre mitigation defaults around what's applied to SECCOMP threads by default in part due to the performance hit as well as other reasons.

For mitigating Spectre Variant Two and Spectre Variant Four (Speculative Store Bypass Disable - SSBD), SECCOMP threads see the mitigation by default while other threads rely on per-thread controls via prctl. Linux kernel developers from the likes of Red Hat and Google are now looking at not applying the mitigations by default to SECCOMP threads for the Spectre V2/V4 mitigations.

SECCOMP is the Linux secure computing mode and used by software like QEMU, OpenSSH, systemd, Snap, and more. Up until now at least the mitigations unless using the kernel parameter overrides would apply their mitigations by default to all SECCOMP threads.

Andrea Arcangeli of Red Hat has laid out a proposal to avoid the SECCOMP default and instead turn the default behavior to that of opting in by the prctl interface. This change would lead to the same affect as booting any current Linux kernel release with the options of "spec_store_bypass_disable=prctl spectre_v2_user=prctl."

See the linked RFC for the full outline of the argued reasons, but the short synopsis is: "Ultimately setting SSBD and STIBP by default for all seccomp jails is a bad sweet spot and bad default with more cons than pros that end up reducing security in the public cloud (by giving an huge incentive to not expose SPEC_CTRL which would be needed to get full security with IBPB after setting nosmt in the guest) and by excessively hurting performance to more secure apps using seccomp that end up having to opt out with SECCOMP_FILTER_FLAG_SPEC_ALLOW."

Google's Kees Cook added, "Agreed. I think this is the right time to flip this switch. I agree with the (very well described) rationales. :) Fundamentally, likely everyone who is interested in manipulating the mitigations are doing so now, and it doesn't make sense (on many fronts) to tie some to seccomp mode any more (which was intended as a temporary defense to gain coverage while sysadmins absorbed what the best practices should be)."

We'll keep monitoring to see if/when this change is accepted.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week