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: <32d00fb2-7187-ed6f-ab1e-287151e82b3a@linux.intel.com>
Date:   Sun, 18 Nov 2018 14:40:28 -0800
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Jiri Kosina <jikos@...nel.org>,
        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>,
        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 11/18/2018 02:17 PM, Jiri Kosina wrote:
> 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,
> 

I think if Thomas can merge my patchset along with Jiri's, the default option will become
opt in for tasks that want the extra security and we won't lose performance.

Tasks that want extra security will enable that via prctl interface or
making themselves non-dumpable.

Admin that want security for all tasks will enable the strict option on boot to
enable STIBP for all tasks.

So my patchset and Jiri's patchset should probably be merged together, so the
users have a choice of the behavior.

Tim