Feature request: ability to set SECCOMP_FILTER_FLAG_SPEC_ALLOW in seccomp profiles

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

[sporksmith]

Related discussion on the Linux kernel mailing list: https://lkml.org/lkml/2020/11/4/1135

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.

[thaJeztah]

I'm not familiar with this option, but does the runtime spec currently define a field to specify this? https://github.com/opencontainers/runtime-spec/blob/v1.0.2/config-linux.md#seccomp. If it's not yet supported there, the first step would be to propose adding this to the runtime specification (otherwise the OCI runtime (runc / crun) would be unable to handle this.

[sporksmith]

I'm not familiar with this option, but does the runtime spec currently define a field to specify this? https://github.com/opencontainers/runtime-spec/blob/v1.0.2/config-linux.md#seccomp.

@thaJeztah Yes, it looks like the flags field accepts SECCOMP_FILTER_FLAG_SPEC_ALLOW

[thaJeztah]

👍 in that case, a PR similar to #42604 would be needed. (Let me know if you're interested in contributing)

[sporksmith]

(Let me know if you're interested in contributing)

Theoretically, maybe, but not sure when I'll have cycles. I won't be sad if someone else does it in the meantime :), which it looks like you're starting to do?

[thaJeztah]

Yes, I was looking at some other changes, and I think with that we should get it "out of the box".

Cleaning up some commits, but will push a PR shortly (for consideration)

[thaJeztah]

Opened #42648

[thaJeztah]

For clarity; support to specify these options in our seccomp profiles was added in #42648, but depends on the runtime (and version of the runtime) that's used wether or not it is actually supported; #42648 (comment)

this won't work (yet) with the current version of runc. (haven't checked if other runtimes, such as crun already support it).

We should probably call that out in the changelog ("for runtimes that support it"), but otherwise I think it should be ok to have this in, as it's not used by default, and if the user updates to a version of the runtime that supports it, they can use a profile with this feature set.

[sporksmith]

Ok; I look forward to this making it into a Docker release :). Thank you!

[sporksmith]

Actually I should double-check - is this now effectively in Docker @ head, and on track to eventually be released? Or are there still some components that need to be updated?

Sorry for the naive question; I'm a Docker end-user and don't fully understand all the components it's gluing together and how :)

[thaJeztah]

It's in docker@head, which is the "work-in-progress" branch for the next (21.xx) release, but (as mentioned) runc does not yet support this, so to be able to use the feature, a newer version of runc with support for this feature has to be released. For that, it's best to open a ticket in https://github.com/opencontainers/runc (if no ticket exists yet for this)

[sporksmith]

Got it; I'll take a look at runc. Thank you!

[KentaTada]

@sporksmith Thank you for your information.

As stated in opencontainers/runtime-spec#1052 (comment), I have already discussed how to implement this feature in opencontainers/runtime-spec#1047