linux-kernel - [RFC PATCH] x86/bugs: Remove 'force' options for retbleed/ITS

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-next>] [day] [month] [year] [list]

Message-ID: <20250626142703.716997-1-david.kaplan@amd.com>
Date: Thu, 26 Jun 2025 09:27:03 -0500
From: David Kaplan <david.kaplan@....com>
To: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.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>
CC: <linux-kernel@...r.kernel.org>
Subject: [RFC PATCH] x86/bugs: Remove 'force' options for retbleed/ITS

Command line options which force-enable a mitigation on an unaffected
processor provide arguably no security value but do create the potential
for problems due to the increased set of mitigation interactions.

For example, setting "indirect_target_selection=force" on an AMD
Retbleed-affected CPU (e.g., Zen2) results in a configuration where the
kernel reports that both ITS and Retbleed are mitigated, but Retbleed is
not in fact mitigated.  In this configuration, untraining of the retbleed
return thunk is enabled but the its_return_thunk is active, rendering the
untraining ineffective.

It is wrong for the kernel to report that a bug is mitigated when it is
not.  While this specific interaction could be directly fixed, the ability
to force-enable these bugs creates unneeded complexity, so remove it.

If removing these options entirely is unacceptable, perhaps for
compatibility reasons, another option could be to only allow forcing on the
affected vendor (i.e., only allow forcing ITS on Intel CPUs), which would
at least limit the potential interactions that need to be analyzed.
Tagging as RFC to prompt discussion on this point.

Signed-off-by: David Kaplan <david.kaplan@....com>
---
 arch/x86/kernel/cpu/bugs.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index e2a8a21efb10..edc913d26381 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1210,8 +1210,6 @@ static int __init retbleed_parse_cmdline(char *str)
 			retbleed_mitigation = RETBLEED_MITIGATION_STUFF;
 		} else if (!strcmp(str, "nosmt")) {
 			retbleed_nosmt = true;
-		} else if (!strcmp(str, "force")) {
-			setup_force_cpu_bug(X86_BUG_RETBLEED);
 		} else {
 			pr_err("Ignoring unknown retbleed option (%s).", str);
 		}
@@ -1411,9 +1409,6 @@ static int __init its_parse_cmdline(char *str)
 		its_mitigation = ITS_MITIGATION_OFF;
 	} else if (!strcmp(str, "on")) {
 		its_mitigation = ITS_MITIGATION_ALIGNED_THUNKS;
-	} else if (!strcmp(str, "force")) {
-		its_mitigation = ITS_MITIGATION_ALIGNED_THUNKS;
-		setup_force_cpu_bug(X86_BUG_ITS);
 	} else if (!strcmp(str, "vmexit")) {
 		its_mitigation = ITS_MITIGATION_VMEXIT_ONLY;
 	} else if (!strcmp(str, "stuff")) {

base-commit: e51a38e71974982abb3f2f16141763a1511f7a3f
-- 
2.34.1