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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <LV3PR12MB9265B16CFC9D3E02C1159DEA94B92@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Sun, 20 Apr 2025 21:00:56 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
CC: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra
	<peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>, Pawan Gupta
	<pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, Dave
 Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H .
 Peter Anvin" <hpa@...or.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 01/16] x86/bugs: Restructure MDS mitigation

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Friday, April 18, 2025 3:43 PM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Peter Zijlstra <peterz@...radead.org>;
> Josh Poimboeuf <jpoimboe@...nel.org>; Pawan Gupta
> <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar <mingo@...hat.com>; Dave
> Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.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