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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.08.2021 15:39, Andrew Cooper wrote:
> 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.

Oh, I see. Yet (nit) then still "spec-ctrl=ssbd".

Jan