linux-kernel - Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

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: <1516724457.9521.156.camel@amazon.co.uk>
Date:   Tue, 23 Jan 2018 16:20:57 +0000
From:   "Woodhouse, David" <dwmw@...zon.co.uk>
To:     Tom Lendacky <thomas.lendacky@....com>,
        Andy Lutomirski <luto@...capital.net>,
        KarimAllah Ahmed <karahmed@...zon.de>
CC:     <linux-kernel@...r.kernel.org>, Andi Kleen <ak@...ux.intel.com>,
        "Andrea Arcangeli" <aarcange@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        "Arjan van de Ven" <arjan@...ux.intel.com>,
        Ashok Raj <ashok.raj@...el.com>,
        "Asit Mallick" <asit.k.mallick@...el.com>,
        Borislav Petkov <bp@...e.de>,
        "Dan Williams" <dan.j.williams@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Janakarajan Natarajan <Janakarajan.Natarajan@....com>,
        Joerg Roedel <joro@...tes.org>,
        "Jun Nakajima" <jun.nakajima@...el.com>,
        Laura Abbott <labbott@...hat.com>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tim Chen <tim.c.chen@...ux.intel.com>, <kvm@...r.kernel.org>,
        <x86@...nel.org>, "Arjan Van De Ven" <arjan.van.de.ven@...el.com>
Subject: Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict
 Indirect Branch Speculation

On Tue, 2018-01-23 at 10:12 -0600, Tom Lendacky wrote:
> 
> >> +.macro UNRESTRICT_IB_SPEC
> >> +    ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_IBRS
> >> +    PUSH_MSR_REGS
> >> +    WRMSR_ASM $MSR_IA32_SPEC_CTRL, $0, $0
> > 
> I think you should be writing 2, not 0, since I'm reasonably
> confident that we want STIBP on.  Can you explain why you're writing
> 0?
> 
> Do we want to talk about STIBP in general?  Should it be (yet another)
> boot option to enable or disable?  If there is STIBP support without
> IBRS support, it could be a set and forget at boot time.

We haven't got patches which enable STIBP in general. The kernel itself
is safe either way with retpoline, or because IBRS implies STIBP too
(that is, there's no difference between writing 1 and 3).

So STIBP is purely about protecting userspace processes from one
another, and VM guests from one another, when they run on HT siblings.

There's an argument that there are so many other information leaks
between HT siblings that we might not care. Especially as it's hard to
*tell* when you're scheduling, whether you trust all the processes (or
guests) on your HT siblings right now... let alone later when
scheduling another process if you need to *now* set STIBP on a sibling
which is no longer save from this process now running.

I'm not sure we want to set STIBP *unconditionally* either because of
the performance implications.

For IBRS we had an answer and it was just ugly. For STIBP we don't
actually have an answer for "how do we use this?". Do we?



Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5210 bytes)