linux-kernel - RE: [PATCH v3 06/35] x86/bugs: Restructure mmio 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:
 <LV3PR12MB9265E88D27667AE6BAD9F7F394FC2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 12 Feb 2025 17:28:23 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.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 v3 06/35] x86/bugs: Restructure mmio mitigation

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Josh Poimboeuf <jpoimboe@...nel.org>
> Sent: Tuesday, February 11, 2025 5:19 PM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>; Peter
> Zijlstra <peterz@...radead.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 v3 06/35] x86/bugs: Restructure mmio mitigation
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Tue, Feb 11, 2025 at 08:35:27PM +0000, Kaplan, David wrote:
> > > > @@ -538,21 +582,6 @@ static void __init mmio_select_mitigation(void)
> > > >       if (!(x86_arch_cap_msr & ARCH_CAP_FBSDP_NO))
> > > >               static_branch_enable(&mds_idle_clear);
> > >
> > > Right here it does the following:
> > >
> > >         /*
> > >          * Enable CPU buffer clear mitigation for host and VMM, if also affected
> > >          * by MDS or TAA. Otherwise, enable mitigation for VMM only.
> > >          */
> > >         if (boot_cpu_has_bug(X86_BUG_MDS) ||
> > > (boot_cpu_has_bug(X86_BUG_TAA) &&
> > >                                               boot_cpu_has(X86_FEATURE_RTM)))
> > >                 setup_force_cpu_cap(X86_FEATURE_CLEAR_CPU_BUF);
> > >
> > > Isn't that a cross-mitigation dependency?  i.e. if
> > > X86_FEATURE_CLEAR_CPU_BUF gets enabled here then the other
> > > mitigations would need to update their mitigation reporting?
> >
> > I don't think so, nobody should be looking at
> > X86_FEATURE_CLEAR_CPU_BUF to determine their mitigation selection,
> > they should only be looking at the other variables like taa_mitigation
> > as done in the verw_mitigation_enabled() function.
>
> But isn't that a bug in the reporting?  AFAICT one of the main motivations for the
> cross dependencies (and the *_update_mitigation()
> functions) is to fix the reporting if something actually ends up getting mitigated by
> something else.
>
> For example, "mds=off tsx_async_abort=full" results in both MDS and TAA being
> reported "Mitigated", because they share the same VERW mitigation.
>
> But in the above case, with X86_BUG_MDS, "mds=off mmio_stale_data=full"
> shows MDS as vulnerable despite it actually being mitigated by VERW.

Does it?  In that case, mds_update_mitigation() will see that verw_mitigation_enabled() is true (because mmio_mitigation!=MMIO_MITIGATION_OFF) and then enable the mds mitigation.

>
> >         /*
> >          * Enable CPU buffer clear mitigation for host and VMM, if also affected
> >          * by MDS or TAA.
> >          *
> >          * Only enable the VMM mitigation if the CPU buffer clear mitigation is
> >          * not being used.
> >          */
> >         if (rfds_mitigation == RFDS_MITIGATION_VERW ||
> >             boot_cpu_has_bug(X86_BUG_MDS) ||
> >             (boot_cpu_has_bug(X86_BUG_TAA) &&
> >              boot_cpu_has(X86_FEATURE_RTM))) {
> >                 setup_force_cpu_cap(X86_FEATURE_CLEAR_CPU_BUF);
> >                 static_branch_disable(&mmio_stale_data_clear);
> >         } else
> >                 static_branch_enable(&mmio_stale_data_clear);
> >
> > Does that sound right?
>
> I *think* that's correct, but this still has the same issue that MDS/TAA are now
> getting mitigated but not reported as such.
>

I think they are getting reported as mitigated because the mmio mitigation was enabled.

--David Kaplan