linux-kernel - Re: STIBP by default.. Revert?

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: <nycvar.YFH.7.76.1811182309540.21108@cbobk.fhfr.pm>
Date:   Sun, 18 Nov 2018 23:17:30 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Casey Schaufler <casey.schaufler@...el.com>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        stable@...r.kernel.org
Subject: Re: STIBP by default.. Revert?

On Sun, 18 Nov 2018, Linus Torvalds wrote:

> > So, I think it's as theoretical as any other spectrev2 (only with the
> > extra "HT" condition added on top).
> 
> What? No.
> 
> It's *way* more theoretical than something like meltdown, which could
> be trivially used to get data from another protection domain.

Oh yeah, I absolutely agree that spectrev2 and Meltdown and completely 
different beasts.

> Have you seen any actual realistic attacks for normal human users?
> Things where the *kernel* should actually care?
> 
> The javascript thing is for the browser to fix up, 

It's probably not just browsers, but anything running JITed sandboxed 
code. So the most straightforward way might be the prctl() aproach, where 
userspace would claim "I do care about this, please fix it up for me". So 
prctl() + perhaps SECCOMP.

Which gets us back to Tim's fixup patch. Do you still prefer the revert, 
given the existence of that? I think that if Tim's fixup makes it through 
(it's currently missing SECCOMP handling, but that is trivial to add on 
top), it might be the best compromise. We'd also have have to make IBPB 
obey it to be consistent (and get even a few more % of performance back), 
but that's easy as well.

Thanks,

-- 
Jiri Kosina
SUSE Labs