Skip to content

Feature request: ability to set SECCOMP_FILTER_FLAG_SPEC_ALLOW in seccomp profiles #42619

@sporksmith

Description

@sporksmith

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions