linux-kernel - Re: [PATCH] x86/speculation: Allow overriding seccomp speculation disable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 21 Mar 2020 19:29:22 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
        Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>
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@...stfloor.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