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]

Message-ID: <20200326141046.giyacwh46bfcbvjy@two.firstfloor.org>
Date:   Thu, 26 Mar 2020 07:10:47 -0700
From:   Andi Kleen <andi@...stfloor.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        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

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

SECCOMP_FILTER_FLAG_SPEC_ALLOW doesn't completely solve the problem because
it enables everything, including cross process defenses, like Spectre.

The motivation of my patch was to only allow to disable SSBD, which
is only relevant for in process attacks, which are completely
mitigated by process isolation, which is now widely deployed.

Completely mitigating Spectre (which could be cross process) is harder,
and it doesn't have have as bad a performance impact as SSBD.

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

It seems to me this design goal is not useful for 
speculation defenses. If an attacker can call prctl they don't
need speculation attacks anymore, they can just read the memory
directly.

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

The seccomp defenses are mainly for web browsers, whose life cycles have
nothing to do with LTS cycles. Web browsers are updated much faster
because of their bazillion other security holes. If someone doesn't
update their web browser they are completely open to other attacks anyways.
So we can assume they do, and the browsers usually enforce it in 
some way.

I'm not aware of anything else that is not a browser that would rely on the
seccomp heuristic. Are you?

Anyways back to the opt-in:

Anyways one way to keep your design goals would be to split the SECCOMP
flags into flags for SSBD and SPECTRE. Then at least the web browser
could reenable it

-Andi