linux-kernel - Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode

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: <84a1bd5c-bdc5-4902-d543-5b276f097d04@linux.intel.com>
Date:   Tue, 4 Dec 2018 10:58:10 -0800
From:   Tim Chen <tim.c.chen@...ux.intel.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        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.w.brandt@...el.com
Subject: Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user
 space protection mode

On 12/04/2018 09:20 AM, Linus Torvalds wrote:

>> 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
> 
> Honestly, it still feels entirely misguided to me.
> 
> The above is not STIBP. It's just "disable IB". There's nothing "ST" about it.
> 
> So on processors where there is no thread ID bit (or per-thread
> predictors), Intel simply SHOULD NOT EXPOSE this at all.
> 
> As it is, I refuse to call this shit "STIBP", because on current CPU's
> that's simply a lie.
> 
> Being "technically correct" is not an excuse. It's just lying. I would
> really hope that we restrict the lying to politicians, and not do it
> in technical documentation.
> 

Linus,

I consulted our HW architects to get their thinking behind the STIBP name
and why it is exposed on CPUs without thread ID bit.

1) Why expose STIBP even when it is just a scratch bit?

VM migration pools prefer that bits which guests have direct access to
(as we recommend for IA32_SPEC_CTRL) do not cause #GP when they are
migrated to different processors in order to prevent guests from crashing
or require restricting VM migration targets. That is why we decided
to allow the STIBP bit to be set and to return the last value written
even on parts where it has no other effect (e.g. Atom parts without
multithreading). There was also discomfort with allowing a bit to be
set, to return the last value written, and to meet the architecturally
documented behavior, but to not enumerate that it is supported. Not
enumerating STIBP would make it more difficult for software to understand
things like how the CPU does reserved bit checks. That is why we enumerate
and support STIBP even when it affects no branch predictors.

2) Why did we not call STIBP "disable IB":

 * It does not disable all indirect branch predictors (on current Core), just a subset
 * It does not disable any indirect branch predictors (on future Core)
 * It does not disable any indirect branch predictors (on Atom parts with no SMT)
 * It does more than disable some indirect branch predictors (on some non-Core)

3) Philosophy for naming architectural bits.

The microcode updates and future hardware changes do a variety
of different micro-architectural behaviors in order to achieve the
goals behind each MSR bit. This means that the names aren't the most
descriptive for each individual project. Had we instead exposed the
different functionality/behavior to software for each CPU then it would
have been a model-specific feature, likely needing different software
behavior for different CPUID family/model/stepping. This would have been
painful for the OS, and even more painful for VMMs and VM migration
pools. This is why we made these bits architectural and used a common
name and definition across the projects.

We don't object to the Linux community using an alternative name for
STIBP (but not Disable IB), so long as it is accurate across our products.
Changing our MSR name in the SDM seems like would it
cause unneeded confusion and work.

Thanks.

Tim