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@amd.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

On Thu, Jun 26, 2025 at 09:27:03AM -0500, David Kaplan wrote:
> 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.

Testing; I use these things for testing. Makes I don't have to run on
affected hardware, I can just force the feature on and inspect the code
and ensures it runs.

If you use force, you get to keep all pieces -- no warranties.

On 6/26/25 17:40, Peter Zijlstra wrote:
> On Thu, Jun 26, 2025 at 09:27:03AM -0500, David Kaplan wrote:
>> 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.
> 
> Testing; I use these things for testing. Makes I don't have to run on
> affected hardware, I can just force the feature on and inspect the code
> and ensures it runs.
> 
> If you use force, you get to keep all pieces -- no warranties.

I concur, however using force won't always guarantee that the code runs 
though, because there can be other condition that must/must not be met 
i.e trying to run ITS on AMD hw (yeah, yeah I know :) ) also required 
commenting out some checks in patch_retpoline.
>

On Thu, Jun 26, 2025 at 06:13:05PM +0300, Nikolay Borisov wrote:

> > Testing; I use these things for testing. Makes I don't have to run on
> > affected hardware, I can just force the feature on and inspect the code
> > and ensures it runs.
> > 
> > If you use force, you get to keep all pieces -- no warranties.
> 
> I concur, however using force won't always guarantee that the code runs
> though, 

Which is why you should run gdb on /proc/kcore to check what you ended
up with :-)

> because there can be other condition that must/must not be met i.e
> trying to run ITS on AMD hw (yeah, yeah I know :) ) also required commenting
> out some checks in patch_retpoline.

Ah, I might not have hit that, due to not actually having any AMD
machines for testing :/

On Thu, Jun 26, 2025 at 04:40:47PM +0200, Peter Zijlstra wrote:
> Testing; I use these things for testing. Makes I don't have to run on
> affected hardware, I can just force the feature on and inspect the code
> and ensures it runs.
> 
> If you use force, you get to keep all pieces -- no warranties.

Right, I don't have a good feeling when "force" makes a machine unmitigated
all of a sudden.

And we're not screaming nearly as loud as possible when =force is supplied and
for such a thing we probably should even taint the kernel.

I'd prefer if we don't expose =force options to the general public but make
them depend on CONFIG_DEBUG_KERNEL perhaps.

IOW, too dangerous.

-- 
Regards/Gruss,
    Boris.

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