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:
 <LV3PR12MB926519BA499E7648F97B569794BB2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Tue, 22 Apr 2025 14:32:07 +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: Tuesday, April 22, 2025 3:19 AM
> 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 Sun, Apr 20, 2025 at 09:00:56PM +0000, Kaplan, David wrote:
> > 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).
>
> Hmm, it still looks weird to me. So let's imagine the CPU is NOT affected by MDS.
> The select function will leave it to OFF.
>
> Then, some other select function will set verw_mitigation_selected.
>
> Now, the mds_update_mitigation() comes in, X86_BUG_MDS is still NOT set so
> we leave mds_mitigation to OFF even though it *technically* gets mitigated?
>
> I guess the reporting aspect does make sense - we don't want to start reporting
> MDS-unaffected CPUs as being MDS mitigated because they're not
> - not really. We just use their mitigation to mitigate other vulns.
>
> Then this comment which explains the logic of verw_mitigation_selected:
>
>         /* If TAA, MMIO, or RFDS are being mitigated, MDS gets mitigated too. */
>
> should probably say that if the CPU is affected by MDS *in any way*
> - the BUG bit is set - then it gets full mitigation.
>
> And this should be the case for all inter-related VERW mitigations: if the CPU is in
> any way affected, it gets mitigated too. If it is not, then it gets only *reported* that it
> is not affected but the mitigation technique can be used for others.
>
> Does that make sense?
>

I think that's correct, although I'd argue the code makes that rather obvious because mds_update_mitigation() immediately returns if the CPU is not affected by MDS.  So you only get an mds mitigation if you are affected by the BUG bit.

--David Kaplan