Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B84E20C48
MIME-Version: 1.0
In-Reply-To: <20180118190842.GA14136@redhat.com>
References: <20180118134800.711245485@infradead.org> <20180118140152.830682032@infradead.org>
 <20180118163745.t5nmwdr53wjsl7o5@treble> <73a5735a-6a5b-0e0f-1f0b-e7cd955880d2@intel.com>
 <a0308ee6-959a-0a78-9205-8de0a60948ac@redhat.com> <20180118182431.xvmk6kzxpzu43b43@treble>
 <20180118190842.GA14136@redhat.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Thu, 18 Jan 2018 15:25:25 -0800
Message-ID: <CALCETrU9Xa6pBd-WuQ9S1s32f7Nb=p9eHEAv7oixf+vZa18ETg@mail.gmail.com>
Subject: Re: [PATCH 23/35] x86/speculation: Add basic speculation control code
To:     Andrea Arcangeli <aarcange@redhat.com>
Cc:     Josh Poimboeuf <jpoimboe@redhat.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        David Woodhouse <dwmw2@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Ashok Raj <ashok.raj@intel.com>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Andi Kleen <ak@linux.intel.com>,
        Arjan Van De Ven <arjan.van.de.ven@intel.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Jun Nakajima <jun.nakajima@intel.com>,
        Asit Mallick <asit.k.mallick@intel.com>,
        Jason Baron <jbaron@akamai.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 18, 2018 at 11:08 AM, Andrea Arcangeli <aarcange@redhat.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.