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: <20250422172537.GCaAfREUU_9RGUwtqK@renoirsky.local>
Date: Tue, 22 Apr 2025 19:25:37 +0200
From: Borislav Petkov <bp@...en8.de>
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" <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

On Tue, Apr 22, 2025 at 02:32:07PM +0000, Kaplan, David wrote:
> [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.

Right, ok.

I'll add a link to this subthread when applying so that we have some
reference to this.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ