RE: [PATCH v3 04/35] x86/bugs: Restructure mds mitigation

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Brendan Jackman <jackmanb@xxxxxxxxxx>
> Sent: Monday, February 10, 2025 10:14 AM
> To: Kaplan, David <David.Kaplan@xxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx>; Peter
> Zijlstra <peterz@xxxxxxxxxxxxx>; Josh Poimboeuf <jpoimboe@xxxxxxxxxx>; Pawan
> Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>;
> Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>; x86@xxxxxxxxxx; H . Peter Anvin
> <hpa@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH v3 04/35] x86/bugs: Restructure mds mitigation
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, 8 Jan 2025 at 21:27, David Kaplan <david.kaplan@xxxxxxx> wrote:
> > +/*
> > + * Speculation Vulnerability Handling
> > + *
> > + * Each vulnerability is handled with the following functions:
> > + *   <vuln>_select_mitigation() -- Selects a mitigation to use.  This should
> > + *                                take into account all relevant command line
> > + *                                options.
> > + *   <vuln>_update_mitigation() -- This is called after all vulnerabilities have
> > + *                                selected a mitigation, in case the selection
> > + *                                may want to change based on other choices
> > + *                                made.  This function is optional.
> > + *   <vuln>_apply_mitigation() -- Enable the selected mitigation.
>
> Maybe also worth calling out cpu_bugs_smt_update() here?

Hmm, how were you thinking?  The 3 functions above are defined for each vulnerability.  So this is more intended as a guide where if adding a new vulnerability, you should define the functions above as needed.

>
> > +/* Return TRUE if any VERW-based mitigation is enabled. */ static
> > +bool __init verw_mitigation_enabled(void) {
> > +       return (mds_mitigation != MDS_MITIGATION_OFF ||
> > +               (taa_mitigation != TAA_MITIGATION_OFF &&
> > +                taa_mitigation != TAA_MITIGATION_TSX_DISABLED) ||
> > +               mmio_mitigation != MMIO_MITIGATION_OFF ||
> > +               rfds_mitigation != RFDS_MITIGATION_OFF); }
>
> Since you defined such nice terminology above, why not use it here and say
> verw_mitigation_selected()?
>
> (Obviously if the alternative was a respin for this trivial issue alone I would prefer to
> merge with the current name!)

I do like that name better, I'll use that unless anyone else objects.

>
> > +static void __init mds_update_mitigation(void) {
> > +       if (!boot_cpu_has_bug(X86_BUG_MDS) || cpu_mitigations_off())
> > +               return;
> > +
> > +       /* If TAA, MMIO, or RFDS are being mitigated, MDS gets mitigated too. */
> > +       if (verw_mitigation_enabled()) {
> > +               if (boot_cpu_has(X86_FEATURE_MD_CLEAR))
> > +                       mds_mitigation = MDS_MITIGATION_FULL;
> > +               else
> > +                       mds_mitigation = MDS_MITIGATION_VMWERV;
> > +       }
>
> This is changing what the user will see in sysfs. This seems good to me, but it
> would be worth calling it out in the commit log I think.

Does it?  What is the case you're thinking of where it is different vs tip?

--David Kaplan