-
Notifications
You must be signed in to change notification settings - Fork 18.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: ability to set SECCOMP_FILTER_FLAG_SPEC_ALLOW in seccomp profiles #42619
Comments
Related discussion on the Linux kernel mailing list: https://lkml.org/lkml/2020/11/4/1135
|
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. |
@thaJeztah Yes, it looks like the |
👍 in that case, a PR similar to #42604 would be needed. (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? |
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) |
Opened #42648 |
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)
|
Ok; I look forward to this making it into a Docker release :). Thank you! |
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 :) |
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) |
Got it; I'll take a look at runc. Thank you! |
@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 |
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
andSCMP_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
.The text was updated successfully, but these errors were encountered: