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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Jan 26, 2018 at 09:59:01AM -0800, Andi Kleen wrote:
> On Fri, Jan 26, 2018 at 09:19:09AM -0800, Linus Torvalds wrote:
> > On Fri, Jan 26, 2018 at 1:11 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> > >
> > > Do we need to look again at the fact that we've disabled the RSB-
> > > stuffing for SMEP?
> > 
> > Absolutely. SMEP helps make people a lot less worried about things,
> > but it doesn't fix the "BTB only contains partial addresses" case.
> > 
> > But did we do that "disable stuffing with SMEP"? I'm not seeing it. In
> > my tree, it's only conditional on X86_FEATURE_RETPOLINE.
> 
> For Skylake we need RSB stuffing even with SMEP to avoid falling back to the
> BTB on underflow.
> 
> It's also always needed with virtualization.

-ECONFUSED, see ==>

Is this incorrect then?
I see:

241          * Skylake era CPUs have a separate issue with *underflow* of the       
242          * RSB, when they will predict 'ret' targets from the generic BTB.      
243          * The proper mitigation for this is IBRS. If IBRS is not supported     
244          * or deactivated in favour of retpolines the RSB fill on context       
245          * switch is required.                                                  
246          */                        

which came from this:

commit c995efd5a740d9cbafbf58bde4973e8b50b4d761
Author: David Woodhouse <dwmw@amazon.co.uk>
Date:   Fri Jan 12 17:49:25 2018 +0000

    x86/retpoline: Fill RSB on context switch for affected CPUs
    
    On context switch from a shallow call stack to a deeper one, as the CPU
    does 'ret' up the deeper side it may encounter RSB entries (predictions for
    where the 'ret' goes to) which were populated in userspace.
    
    This is problematic if neither SMEP nor KPTI (the latter of which marks
    userspace pages as NX for the kernel) are active, as malicious code in
    userspace may then be executed speculatively.
    
    Overwrite the CPU's return prediction stack with calls which are predicted
    to return to an infinite loop, to "capture" speculation if this
    happens. This is required both for retpoline, and also in conjunction with
    IBRS for !SMEP && !KPTI.
    
    On Skylake+ the problem is slightly different, and an *underflow* of the
    RSB may cause errant branch predictions to occur. So there it's not so much
    overwrite, as *filling* the RSB to attempt to prevent it getting
    empty. This is only a partial solution for Skylake+ since there are many
==>other conditions which may result in the RSB becoming empty. The full	<==
==>solution on Skylake+ is to use IBRS, which will prevent the problem even	<==
    when the RSB becomes empty. With IBRS, the RSB-stuffing will not be
    required on context switch.
    
    
    Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Arjan van de Ven <arjan@linux.intel.com>


The "full solution" is what is making me confused.
> 
> -Andi