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;
Date:   Thu, 18 Jan 2018 20:08:42 +0100
From:   Andrea Arcangeli <aarcange@redhat.com>
To:     Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     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>,
        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>
Subject: Re: [PATCH 23/35] x86/speculation: Add basic speculation control code
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180118182431.xvmk6kzxpzu43b43@treble>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

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.

Said that the CPU should better achieve such semantics without really
internally issuing an IBPB of course, but you can think at the current
IBRS as "STIBP; IBPB". That IBPB immediately after the STIBP makes a
difference to the non HT attacks possible on host userland.

user_smt wouldn't solve all cases that user_ibrs solves, but it'd be
ideal if critical user apps are built with retpolines and the only
concern left is a HT/SMT attack on those only need to care about
HT/SMT.

To begin with, user_ibrs would be more important than user_stibp.

On a side note: stibp isn't always available, it requires a new cpuid
check on bit 27 too, you can still write to it but it won't #gp, on
some CPUs it's simply implicit and you can write to it, but it's a
noop. I haven't figured exactly to differentiate when it's disabled or
implicitly enabled when not enumerated in cpuid.