Messages in this thread Patch in this message | | | From | Andi Kleen <> | Subject | [PATCH] x86/speculation: Allow overriding seccomp speculation disable | Date | Thu, 12 Mar 2020 16:12:22 -0700 |
| |
From: Andi Kleen <ak@linux.intel.com>
seccomp currently force enables the SSBD and IB mitigations, which disable certain features in the CPU to avoid speculation attacks at a performance penalty.
This is a heuristic to detect applications that may run untrusted code (such as web browsers) and provide mitigation for them.
At least for SSBD the mitigation is really only for side channel leaks inside processes.
There are two cases when the heuristic has problems:
- The seccomp user has a superior mitigation and doesn't need the CPU level disables. For example for a Web Browser this is using site isolation, which separates different sites in different processes, so side channel leaks inside a process are not of a concern.
- Another case are seccomp users who don't run untrusted code, such as sshd, and don't really benefit from SSBD
As currently implemented seccomp force enables the mitigation so it's not possible for processes to opt-in that they don't need mitigations (such as when they already use site isolation).
In some cases we're seeing significant performance penalties of enabling the SSBD mitigation on web workloads.
This patch changes the seccomp code to not force enable, but merely enable, the SSBD and IB mitigations.
This allows processes to use the PR_SET_SPECULATION prctl after running seccomp and reenable SSBD and/or IB if they don't need any extra mitigation.
The effective default has not changed, it just allows processes to opt-out of the default.
It's not clear to me what the use case for the force disable is anyways. Certainly if someone controls the process, and can run prctl(), they can leak data in all kinds of ways anyways, or just read the whole memory map.
Longer term we probably need to discuss if the seccomp heuristic is still warranted and should be perhaps changed. It seemed like a good idea when these vulnerabilities were new, and no web browsers supported site isolation. But with site isolation widely deployed -- Chrome has it on by default, and as I understand it, Firefox is going to enable it by default soon. And other seccomp users (like sshd or systemd) probably don't really need it. Given that it's not clear the default heuristic is still a good idea.
But anyways this patch doesn't change any defaults, just let's applications override it.
Signed-off-by: Andi Kleen <ak@linux.intel.com> --- arch/x86/kernel/cpu/bugs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index ed54b3b21c39..f15ae9bfd7ad 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1215,9 +1215,9 @@ int arch_prctl_spec_ctrl_set(struct task_struct *task, unsigned long which, void arch_seccomp_spec_mitigate(struct task_struct *task) { if (ssb_mode == SPEC_STORE_BYPASS_SECCOMP) - ssb_prctl_set(task, PR_SPEC_FORCE_DISABLE); + ssb_prctl_set(task, PR_SPEC_DISABLE); if (spectre_v2_user == SPECTRE_V2_USER_SECCOMP) - ib_prctl_set(task, PR_SPEC_FORCE_DISABLE); + ib_prctl_set(task, PR_SPEC_DISABLE); } #endif -- 2.24.1
| |