-
Notifications
You must be signed in to change notification settings - Fork 18.9k
Description
TLDR: I propose an option to disable the Speculative Store Bypass mitigation when using seccomp, via an option in the json profile, and/or via a command-line flag. I also recommend disabling it in the default profile/configuration.
Docker/moby currently enables the Speculative Store Bypass mitigation when using seccomp. This is the default for the seccomp syscall and for libseccomp, but can be opted out of via SECCOMP_FILTER_FLAG_SPEC_ALLOW and SCMP_FLTATR_CTL_SSB, respectively. Once enabled, it cannot be disabled from the calling thread or its children.
This mitigation can add substantial overhead to CPU-bound workloads. For the simulation tool I help develop, it results in simulations taking about 50% longer to run.
We're able to avoid this overhead using --security-opt seccomp=unconfined, but this isn't always an option when running on a shared host system.
My understanding of this mitigation is that it protects from malicious code in the same address space (e.g. in the same OS process) from reading memory it otherwise wouldn't be able to. This is important for software sandboxes like a web browser that runs untrusted code within its own process. As far as I can tell, it isn't needed to protect Docker or its host operating system from processes running inside a Docker container. https://www.redhat.com/en/blog/speculative-store-bypass-explained-what-it-how-it-works
It'd be helpful if there were at least an option to disable this mitigation in the seccomp profile and/or a command-line flag, so that we could opt out of this without disabling seccomp entirely.
I think it'd even make sense for this to be the default. I suppose someone somewhere might be implicitly relying on the current default - e.g. running untrusted code in a (more) trusted software sandbox inside a Docker container, and relying on Docker to have already turned on this mitigation. Generally though any such sandbox should already be explicitly opting into this mitigation via its own usage of seccomp, or directly enabling it through the PR_SET_SPECULATION_CTRL prctl.