[<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