On 04/21/2018 05:41 PM, speck for Linus Torvalds wrote:

> On Sat, 21 Apr 2018, speck for Borislav Petkov wrote:
>>
>> I prefer X86_FEATURE_MDD and X86_FEATURE_USE_MDD which is
>> straight-forward and in line with the other mitigations. And we query
>> the USE_MDD flag only. The MDD one will be for /proc/cpuinfo and USE_MDD
>> used by the code.
> 
> At the risk of bike shedding, can we *please* just write out "Store buffer 
> bypass" and "Memory disambiguation" instead of using SBB amd MD?

Very reasonable.

> The patches aren't so big, and these names won't be used so much that we 
> can't use longer names. Yes, yes, we use PTI for the page table isolation, 
> but that had a much wider impact. For Spectre v1 we at least use _half_ 
> words like "nospec".
> 
> Maybe even X86_FEATURE_STBUF_BYPASS?
> 
> And X86_FEATURE_STBUF_BYPASS_MITIGATE?
> And the same goes for the kernel command line. Saying "ssb=auto" is not 
> helpful to *anybody*.

Can you make a call on the above now? We're happy to go along with
whatever but need to get the other arches aligned behind whatever we're
doing (IBM p, z, and Arm are working on patches as well as others), and
then crank on the distro patches based upon whatever is agreed here.

So might I ask your opinion of the following list of terms/uses?

(we've been previously asked by Thomas to retain the inverted logic - so
you enable a mitigation which disables a CPU performance optimization)

* spec_store_bypass_disable=auto/off/on
* /sys/devices/system/cpu/vulnerabilities/speculative_store_bypass
* X86_FEATURE_SPEC_STORE_BYPASS_DISABLE
* X86_FEATURE_USE_SPEC_STORE_BYPASS_DISABLE

> Nobody is going to get carpal tunnel syndrome from typing that too often. 
> I guarantee it.

:)

Jon.

P.S. I didn't say "stbuf" in the above because it's not required that a
uarch implement only speculation on the store buffer. It could be that a
uarch uses an integrated load/store queue (LSQ) and searches that, or it
could be that stores are tracked in another manner (e.g. IBM). All the
exploit relies upon is close-to-retirement store conflict handling. And
we have several variants of this exploit coming up that rely upon slight
twists of store-to-load forwarding. I expect those will come up here.

-- 
Computer Architect | Sent from my Fedora powered laptop