Messages in this thread | | | Date | Sat, 21 Mar 2020 19:29:22 -0700 | From | Kees Cook <> | Subject | Re: [PATCH] x86/speculation: Allow overriding seccomp speculation disable |
| |
On Sat, Mar 21, 2020 at 03:46:29PM +0100, Thomas Gleixner wrote: > Cc+: Seccomp maintainers ....
Thanks!
> Andi Kleen <andi@firstfloor.org> writes: > > [...] > > > > 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.
None of this commit makes sense to me. :)
The point of the defaults was to grandfather older seccomp users into speculation mitigations. Newly built seccomp users can choose to disable this with SECCOMP_FILTER_FLAG_SPEC_ALLOW when applying seccomp filters. The rationale was that once a process knows how to manage its exposure, it can choose to leave off the automatic enabling. I don't see any mention of that method in the commit log, so if there is some reason it's not workable, that would need to be discussed first.
And the force disable matches the design goals of seccomp: no applied restrictions can be later relaxed for a process. I'm more in favor of changing the behavior of SPEC_STORE_BYPASS_CMD_AUTO, but probably not for another 3 years at least. (To get us to at least 5 years since Meltdown, which is relatively close to various longer LTS cycles.)
-Kees
-- Kees Cook
| |