linux-kernel - Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

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: <CALCETrU9Xa6pBd-WuQ9S1s32f7Nb=p9eHEAv7oixf+vZa18ETg@mail.gmail.com>
Date:   Thu, 18 Jan 2018 15:25:25 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Ashok Raj <ashok.raj@...el.com>,
        Tim Chen <tim.c.chen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@...el.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Jun Nakajima <jun.nakajima@...el.com>,
        Asit Mallick <asit.k.mallick@...el.com>,
        Jason Baron <jbaron@...mai.com>
Subject: Re: [PATCH 23/35] x86/speculation: Add basic speculation control code

On Thu, Jan 18, 2018 at 11:08 AM, Andrea Arcangeli <aarcange@...hat.com> wrote:
> On Thu, Jan 18, 2018 at 12:24:31PM -0600, Josh Poimboeuf wrote:
>> On Thu, Jan 18, 2018 at 06:12:36PM +0100, Paolo Bonzini wrote:
>> > On 18/01/2018 18:08, Dave Hansen wrote:
>> > > On 01/18/2018 08:37 AM, Josh Poimboeuf wrote:
>> > >>>
>> > >>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> > >>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> > >>> @@ -3932,6 +3932,7 @@
>> > >>>                         retpoline         - replace indirect branches
>> > >>>                         retpoline,generic - google's original retpoline
>> > >>>                         retpoline,amd     - AMD-specific minimal thunk
>> > >>> +                       ibrs              - Intel: Indirect Branch Restricted Speculation
>> > >> Are there plans to add spectre_v2=ibrs_always to prevent SMT-based
>> > >> attacks?
>> > >
>> > > What does "ibrs_always" mean to you?
>>
>> Maybe ibrs_always isn't the best name.  Basically we need an option to
>> protect user-user attacks via SMT.
>>
>> It could be implemented with IBRS=1, or STIBP, or as part of the
>> mythical IBRS_ATT.
>
> User stibp or user ibrs would be different things, both would be valid
> for different use cases, and the user stibp should perform better.
>
> Leaving ibrs on when returning from kernel to userland (or setting
> ibrs if kernel used retpolines instead of ibrs) achieves stronger
> semantics than just setting SPEC_CTRL with stibp when returning to
> userland.

I read the whitepaper that documented the new MSRs a couple days ago
and I'm now completely unable to find it.  If anyone could send the
link, that would be great.

>From memory, however, the docs were quite clear that setting leaving
IBRS set when entering user mode or guest mode does not guarantee any
particular protection unless an additional CPUID bit (the name of
which I forget) is set, and that current CPUs will *not* get that bit
set by microcode update.  IOW the protection given is that, if you set
IBRS bit zero after entry to kernel mode, you are protected until you
re-enter user mode.  When you're in user mode, you're not protected.
When you return back to kernel mode, you *still* aren't protected no
matter what value is in the MSR until you write 1 again.

>
> That is true no matter if kernel is using retpolines or ibrs.
>
> IBRS is semantically equivalent to "STIBP; IBPB", so user_ibrs is
> always inclusive of user_stibp.

Are you quite sure?  I had the impression that IBPB was much slower
than writing 1 to IBRS and that writing 1 to IBRS has much more
limited effects.