Message-ID: <f4b903ef-828c-0b05-29c6-6f71677d120d@linux.intel.com>
Date:   Mon, 3 Dec 2018 17:38:54 -0800
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Lutomirski <luto@...nel.org>,
        Jiri Kosina <jkosina@...e.cz>, thomas.lendacky@....com,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Andi Kleen <ak@...ux.intel.com>, dave.hansen@...el.com,
        Casey Schaufler <casey.schaufler@...el.com>,
        "Mallick, Asit K" <asit.k.mallick@...el.com>,
        "Van De Ven, Arjan" <arjan@...ux.intel.com>, jcm@...hat.com,
        longman9394@...il.com, Greg KH <gregkh@...uxfoundation.org>,
        david.c.stewart@...el.com, Kees Cook <keescook@...omium.org>,
        Jason Brandt <jason.w.brandt@...el.com>
Subject: Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user
 space protection mode

On 11/25/2018 12:40 PM, Linus Torvalds wrote:
> [ You forgot to fix your quilt setup.. ]
> 
> On Sun, 25 Nov 2018, Thomas Gleixner wrote:
>>
>> The mitigation guide documents how STIPB works:
>>
>>    Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
>>    prevents the predicted targets of indirect branches on any logical
>>    processor of that core from being controlled by software that executes
>>    (or executed previously) on another logical processor of the same core.
> 
> Can we please just fix this stupid lie?
> 
> Yes, Intel calls it "STIBP" and tries to make it out to be about the
> indirect branch predictor being per-SMT thread.
> 
> But the reason it is unacceptable is apparently because in reality it just
> disables indirect branch prediction entirely. So yes, *technically* it's
> true that that limits indirect branch prediction to just a single SMT
> core, but in reality it is just a "go really slow" mode.
> 
> If STIBP had actually just keyed off the logical SMT thread, we wouldn't
> need to have worried about it in the first place.
> 
> So let's document reality rather than Intel's Pollyanna world-view.
> 
> Reality matters. It's why we had to go all this. Lying about things
> and making it appear like it's not a big deal was why the original
> patch made it through without people noticing.
> 


To make the usage of STIBP and its working principles clear,
here are some additional explanations of STIBP from our Intel
HW architects.  This should also help answer some of the questions
from Thomas and others on STIBP's usages with IBPB and IBRS.

Thanks.

Tim

---

STIBP
^^^^^
Implementations of STIBP on existing Core-family processors (where STIBP
functionality was added through a microcode update) work by disabling
branch predictors that both:

    1. Contain indirect branch predictions for both hardware threads, and
    2. Do not contain a dedicated thread ID bit 

Unlike IBRS and IBPB, STIBP does not affect all branch predictors
that contain indirect branch predictions. STIBP only affects those
branch predictors where software on one hardware thread can create a
prediction that can then be used by the other hardware thread. This is
part of what makes STIBP have lower performance overhead than IBRS on
current implementations.

IBRS is a superset of STIBP functionality; thus, setting both STIBP and
IBRS is redundant. On processors without enhanced IBRS, we recommend
using retpoline or setting IBRS only during ring 0 and VMM modes. IBPB
should be used when switching to a different process/guest that does
not trust the last process/guest that ran on a particular hardware
thread. For performance reasons, IBRS should not be left set during
application execution.

Processes that are particularly security-sensitive may set STIBP when
they execute to prevent their indirect branch predictions from being
controlled by another hardware thread on the same physical core. On
existing Core-family processors, this comes at significant performance
cost to both hardware threads due to disabling some indirect branch
predictors (as described earlier). Because of this, we do not recommend
setting STIBP during all application execution.

STIBP is architecturally defined to apply to all hardware threads on
the physical core on which it is set. Because of this, STIBP can be set
when running an untrusted process to ensure that the untrusted process
does not control the indirect branch predictions of software running
on other hardware threads (for example, threads that do not have STIBP
or IBRS set) while STIBP is still set. Before running with both STIBP
and IBRS cleared, an IBPB can be executed to ensure that any indirect
branch predictions that were installed by the untrusted process while
STIBP was set are not used by the other hardware thread once STIBP and
IBRS are cleared. Regardless of the usage model, STIBP should be used
judiciously due to its impact on performance.

Enhanced IBRS is a feature that also provides a superset of STIBP
functionality; therefore it is redundant to set both STIBP and enhanced
IBRS. Processors with enhanced IBRS add a thread ID bit to the needed
indirect branch predictors and use that bit to ensure that indirect
branch predictions are only used by the thread that created them.

On processors with enhanced IBRS support, we recommend setting IBRS to 1
and left set. The traditional IBRS model of setting IBRS only during ring
0 execution is just as secure on parts with enhanced IBRS support as it is
on parts with vanilla IBRS, but the WRMSRs on ring transitions and/or VM
exit/entry will cost performance compared to just leaving IBRS set. Again,
there is no need to use STIBP when IBRS is set. However, IBPB should
still be used when switching to a different application/guest that does
not trust the last application/guest that ran on a particular hardware
thread. Guests in a VM migration pool that includes hardware without
enhanced IBRS may not have IA32_ARCH_CAPABILITIES.IBRS_ALL (enhanced IBRS)
enumerated to them and thus may use the traditional IBRS usage model of
setting IBRS only in ring 0. For performance reasons, once a guest has
been shown to frequently write IA32_SPEC_CTRL, we do not recommend that
the VMM cause a VM exit on such WRMSRs. The VMM running on processors
that support enhanced IBRS should allow the IA32_SPEC_CTRL-writing guest
to control guest IA32_SPEC_CTRL. The VMM should thus set IBRS after VM
exits from such guests to protect itself (or use alternative techniques
like retpoline, secret removal, or indirect branch removal).

 

Powered by blists - more mailing lists