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
