Messages in this thread | | | From | Tim Chen <> | Subject | Re: [patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode | Date | Tue, 4 Dec 2018 10:58:10 -0800 |
| |
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
| |