Linux Preparing To Slightly Loosen Its Spectre Defaults
A change first proposed last year to the Linux kernel's Spectre mitigation defaults looks like it will soon be sent in for the mainline kernel.
The change is in regards to the default mitigation value for Spectre V2 for user-space tasks and Spectre V4 / Speculative Store Bypass. For the kernel options of "spec_store_bypass_disable" and "spectre_v2_user", the current default is the "seccomp" mode. With that default behavior the mitigations are only applied when opted into per-thread via the PRCTL interface (or otherwise a process inherits the mitigation when forked) or is enabled by default for all SECCOMP threads.
With Linux's SECCOMP being about secure computing and used for process isolation and sandboxing by a wide variety of software, it does make sense to have these Spectre mitigations by default there... Or to upstream developers at least did. The pending change now is to drop that spectre_v2_user/spec_store_bypass_disable by default for SECCOMP threads and just leave it to the "prctl" behavior as the default.
The argument to change the default has been that the SECCOMP default hasn't been entirely effective with various other security vulnerabilities out there or their default behavior and various other shortcomings or other exposure to attack by notable SECCOMP users. Plus by now a few years after Spectre first came to light, most Linux system administrators have already figured out their desired tuning configuration to use on production systems with the various speculative execution security tunables.
By reducing the default/out-of-the-box behavior for those Spectre settings from "seccomp" to "prctl", it would help with the out-of-the-box performance of SECCOMP tasks by avoiding that overhead.
The change was first proposed last Novemner. The patch by Andrea Arcangeli summed up the situation as "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."
The news this weekend is that Google's Kees Cook is planning to move ahead and pick up that patch making the default change unless there are any new objections on the matter.
The change is in regards to the default mitigation value for Spectre V2 for user-space tasks and Spectre V4 / Speculative Store Bypass. For the kernel options of "spec_store_bypass_disable" and "spectre_v2_user", the current default is the "seccomp" mode. With that default behavior the mitigations are only applied when opted into per-thread via the PRCTL interface (or otherwise a process inherits the mitigation when forked) or is enabled by default for all SECCOMP threads.
With Linux's SECCOMP being about secure computing and used for process isolation and sandboxing by a wide variety of software, it does make sense to have these Spectre mitigations by default there... Or to upstream developers at least did. The pending change now is to drop that spectre_v2_user/spec_store_bypass_disable by default for SECCOMP threads and just leave it to the "prctl" behavior as the default.
The argument to change the default has been that the SECCOMP default hasn't been entirely effective with various other security vulnerabilities out there or their default behavior and various other shortcomings or other exposure to attack by notable SECCOMP users. Plus by now a few years after Spectre first came to light, most Linux system administrators have already figured out their desired tuning configuration to use on production systems with the various speculative execution security tunables.
By reducing the default/out-of-the-box behavior for those Spectre settings from "seccomp" to "prctl", it would help with the out-of-the-box performance of SECCOMP tasks by avoiding that overhead.
The change was first proposed last Novemner. The patch by Andrea Arcangeli summed up the situation as "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."
The news this weekend is that Google's Kees Cook is planning to move ahead and pick up that patch making the default change unless there are any new objections on the matter.
5 Comments