[lkml]   [2020]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: [PATCH] x86/speculation: Allow overriding seccomp speculation disable
Andi Kleen <> writes:

Cc+: Seccomp maintainers ....

> From: Andi Kleen <>
> 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,

I'm sure I asked you to do

git grep "This patch" Documentation/process/


> 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.

It changes the enforcement and I really want the seccomp people to have
a say here.



> Signed-off-by: Andi Kleen <>
> ---
> 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

 \ /
  Last update: 2020-03-21 15:46    [W:0.161 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site