linux-kernel - Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app protection modes

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:   Mon, 19 Nov 2018 20:39:41 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Andrea Arcangeli <aarcange@...hat.com>
cc:     Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Jon Masters <jcm@...hat.com>,
        Waiman Long <longman9394@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Willy Tarreau <w@....eu>
Subject: Re: [Patch v5 11/16] x86/speculation: Add Spectre v2 app to app
 protection modes

On Mon, 19 Nov 2018, Andrea Arcangeli wrote:

> Generally speaking the untrusted code that would try to use spectrev2
> to attack the other processes is more likely to run inside SECCOMP
> jail than outside, so if SECCOMP should be used as a best effort
> heuristic to decide when to enable STIBP, it would make more sense to
> enable STIBP outside SECCOMP, and not inside. I.e. the exact opposite
> of what you're proposing above.

Hmm, that's a very good point. But I actually don't see why both 
directions wouldn't be possible real-blackhat-world scenarios. So perhaps 
we'd want, under the basic asumption that "SECCOMP should really be 
sandboxed from outisde interventions and from causing them from inside as 
well", flush on both switch-to-seccomp and switch-from-seccomp?

> Code running under SECCOMP is not necessarily less performance critical 
> so if we don't protect what's outside, I doubt we should protect what's 
> inside.
> 
> In short I doubt we can make an association between SECCOMP and STIBP
> here and we should leave SECCOMP alone this time.
> 
> The prctl is a nice to have feature, but it is more for specialized
> apps like gpg that aren't performance critical anyway.
> 
> The system wide default is more a decision the admin should do without 
> having to add prctl wrappers to all apps or change config files. Clearly 
> the prctl won't hurt especially if it can be overridden (and forced off) 
> with the global tweak like with the ssbd options. The only thing I don't 
> understand is why one has to reboot to change the global defaults for 
> ssbd and now STIBP (unless you're already planning to make the global 
> tweak runtime tunable) despite there's no runtime benefit by forcing 
> these decision at boot time only. Would be nice to add runtime tweak 
> options for at least STIBP and SSBD that aren't confined to the prctl.

So if I understand you correctly, what you are proposing here is to keep 
the current code, but just switch the default, and make it 
runtime/boottime togglable?

Thanks,

-- 
Jiri Kosina
SUSE Labs