RE: [PATCH v5 01/16] x86/bugs: Restructure MDS mitigation

Kaplan, David
2025-04-20T21:01:01Z

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@alien8.de>
> Sent: Friday, April 18, 2025 3:43 PM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Thomas Gleixner <tglx@linutronix.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 v5 01/16] x86/bugs: Restructure MDS mitigation
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Fri, Apr 18, 2025 at 11:17:06AM -0500, David Kaplan wrote:
> > @@ -284,6 +314,9 @@ enum rfds_mitigations { static enum
> > rfds_mitigations rfds_mitigation __ro_after_init =
> > IS_ENABLED(CONFIG_MITIGATION_RFDS) ? RFDS_MITIGATION_AUTO
> :
> > RFDS_MITIGATION_OFF;
> >
> > +/* Set if any of MDS/TAA/MMIO/RFDS are going to enable VERW. */
> > +static bool verw_mitigation_selected __ro_after_init;
> > +
>
> Yeah, pls pull that one up - see diff at the end.
>
> > static void __init mds_select_mitigation(void) {
> > if (!boot_cpu_has_bug(X86_BUG_MDS) || cpu_mitigations_off()) {
> > @@ -294,12 +327,34 @@ static void __init mds_select_mitigation(void)
> > if (mds_mitigation == MDS_MITIGATION_AUTO)
> > mds_mitigation = MDS_MITIGATION_FULL;
> >
> > + if (mds_mitigation == MDS_MITIGATION_OFF)
> > + return;
> > +
> > + verw_mitigation_selected = true; }
> > +
> > +static void __init mds_update_mitigation(void) {
> > + if (!boot_cpu_has_bug(X86_BUG_MDS) || cpu_mitigations_off())
> > + return;
>
> Can we simply do
>
> if (mds_mitigation == MDS_MITIGATION_OFF)
> return;
>
> here?
>
> We already checked the X86_BUG and cpu_mitigations_off() in the select function.

No, the point of mds_update_mitigation() is to enable mds mitigations if one of the other similar bugs (TAA/MMIO/RFDS) is being mitigated.

So even if mds_mitigation was MDS_MITIGATION_OFF, it might need to change to something else because one of the other bugs was mitigated.

>
> > +
> > + /* If TAA, MMIO, or RFDS are being mitigated, MDS gets mitigated
> > + too. */
>
> A version of that comment is already over verw_mitigation_selected's definition.

I could remove it here, although I wonder if it's worth keeping given the confusion above. Or perhaps it can be rephrased to specifically talk about how mds gets mitigated even if it happened to be disabled.

>
> > + if (verw_mitigation_selected)
> > + mds_mitigation = MDS_MITIGATION_FULL;
>
> So we have this here now:
>
> if (mds_mitigation == MDS_MITIGATION_OFF)
> return;
>
> if (verw_mitigation_selected)
> mds_mitigation = MDS_MITIGATION_FULL;
>
> or what you have:
>
> 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_selected)
> mds_mitigation = MDS_MITIGATION_FULL;
>
>
>
> Now, if the CPU is not affected by MDS, this second branch won't ever get set
> because we will return earlier.
>
> Which then means that "If TAA, MMIO, or RFDS are being mitigated, MDS gets
> mitigated too" is not really true.
>
> IOW, I'm wondering if this would be the more fitting order:
>
> static void __init mds_update_mitigation(void) {
> if (verw_mitigation_selected)
> mds_mitigation = MDS_MITIGATION_FULL;
>
> if (mds_mitigation == MDS_MITIGATION_OFF)
> return;
>
> I.e., if *any* mitigation did set verw_mitigation_selected, even if the CPU is not
> affected by MDS, it must set mds_mitigation to FULL too.
>
> Hmmm?
>

I'm not sure this is right, it certainly diverges from upstream where mds is only marked as mitigated if the CPU is actually vulnerable to mds. I also think that imo it generally does not make sense to mark a bug as mitigated if the CPU isn't vulnerable (seems to increase risk of future bugs in the logic).

Thanks
--David Kaplan