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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250422081901.GAaAdQ9aB5KTI5INO7@renoirsky.local>
Date: Tue, 22 Apr 2025 10:19:01 +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 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'm basically thinking out loud here, trying to explain (to myself
mostly:)) how this verw_mitigation_selected is going to be employed.

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