Re: [PATCH 3/3] x86/amd: Use newer SSBD mechanisms if they exist

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 19/08/2021 15:59, Jan Beulich wrote:
> On 17.08.2021 16:30, Andrew Cooper wrote:
>> The opencoded legacy Memory Disambiguation logic in init_amd() neglected
>> Fam19h for the Zen3 microarchitecture.
>>
>> In practice, all Zen2 based system (AMD Fam17h Model >= 0x30 and Hygon Fam18h
>> Model >= 0x4) have the architectural MSR_SPEC_CTRL and the SSBD bit within it.
>>
>> Implement the algorithm given in AMD's SSBD whitepaper, and leave a
>> printk_once() behind in the case that no controls can be found.
>>
>> This now means that a user choosing `spec-ctrl=no-ssb` will actually turn off
>> Memory Disambiguation on Fam19h/Zen3 systems.
> Aiui you mean `spec-ctrl=no-ssbd` here? And the effect would then be
> to turn _on_ Memory Disambiguation, unless the original comment was
> the wrong way round? I'm also concerned by this behavioral change:
> I think opt_ssbd would want to become a tristate, such that not
> specifying the option at all will not also result in turning the bit
> off even if it was on for some reason (firmware?). Similarly
> "spec-ctrl=no" and "spec-ctrl=no-xen" imo shouldn't have this effect.

I messed that bit of the description up.  I means `spec-ctrl=ssb`, i.e.
the non-default value.

We do not disable Memory Disambiguation (the speculative feature which
causes the Speculative Store Bypass vulnerability) by default (due to
the perf hit), but if the user explicitly asks for it using the
available command line option, nothing currently happens on Fam19h.

~Andrew