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

Kaplan, David
2025-02-10T17:17:26Z

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Brendan Jackman <jackmanb@google.com>
> Sent: Monday, February 10, 2025 10:14 AM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>; Borislav Petkov <bp@alien8.de>; Peter
> Zijlstra <peterz@infradead.org>; Josh Poimboeuf <jpoimboe@kernel.org>; Pawan
> Gupta <pawan.kumar.gupta@linux.intel.com>; Ingo Molnar <mingo@redhat.com>;
> Dave Hansen <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> <hpa@zytor.com>; linux-kernel@vger.kernel.org
> 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@amd.com> 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