Explicitly disallow enabling mitigations at runtime for kernels that were
built with CONFIG_CPU_MITIGATIONS=n, which currently is possible only on
x86 (via x86's SPECULATION_MITIGATIONS menuconfig).

On x86, a large pile of Kconfigs are buried behind SPECULATION_MITIGATIONS,
and trying to provide sane behavior for retroactively enabling mitigations
is extremely difficult, bordering on impossible.  E.g. page table isolation
and call depth tracking requrie build-time support, BHI mitigations will
still be off without additional kernel parameters, etc.

Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 arch/x86/Kconfig                                | 10 +++++++---
 kernel/cpu.c                                    |  2 ++
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 902ecd92a29f..73cc672de9c3 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3423,6 +3423,9 @@
 			arch-independent options, each of which is an
 			aggregation of existing arch-specific options.
 
+			Note, "mitigations" is supported on x86 if and only if
+			the kernel was built with SPECULATION_MITIGATIONS=y.
+
 			off
 				Disable all optional CPU mitigations.  This
 				improves system performance, but it may also
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a0eca6313276..3021976e34cf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2494,10 +2494,14 @@ menuconfig SPECULATION_MITIGATIONS
 	default y
 	help
 	  Say Y here to enable options which enable mitigations for
-	  speculative execution hardware vulnerabilities.
+	  speculative execution hardware vulnerabilities.  Mitigations can
+	  be disabled or restricted to SMT systems at runtime via the
+	  "mitigations" kernel parameter.
 
-	  If you say N, all mitigations will be disabled. You really
-	  should know what you are doing to say so.
+	  If you say N, all mitigations will be disabled.  This CANNOT be
+	  overridden at runtime.
+
+	  Say 'Y', unless you really know what you are doing.
 
 if SPECULATION_MITIGATIONS
 
diff --git a/kernel/cpu.c b/kernel/cpu.c
index bb0ff275fb46..e3f2b34bb378 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -3214,6 +3214,8 @@ static int __init mitigations_parse_cmdline(char *arg)
 {
 	if (!strcmp(arg, "off"))
 		cpu_mitigations = CPU_MITIGATIONS_OFF;
+	else if (!IS_ENABLED(CONFIG_CPU_MITIGATIONS))
+		pr_crit("Kernel compiled without mitigations, ignoring 'mitigations'; system may still be vulnerable\n");
 	else if (!strcmp(arg, "auto"))
 		cpu_mitigations = CPU_MITIGATIONS_AUTO;
 	else if (!strcmp(arg, "auto,nosmt"))
-- 
2.44.0.683.g7961c838ac-goog

On Tue, Apr 16, 2024 at 05:15:07PM -0700, Sean Christopherson wrote:
> Explicitly disallow enabling mitigations at runtime for kernels that were
> built with CONFIG_CPU_MITIGATIONS=n, which currently is possible only on
> x86 (via x86's SPECULATION_MITIGATIONS menuconfig).

Hm, so the umbrella term is CPU_MITIGATIONS, the x86-one is
SPECULATION_MITIGATIONS.

I wanna streamline our namespacing and say, the arch agnostic term
should be CPU_MITIGATIONS and the x86 one should be then
X86_CPU_MITIGATIONS, the Arm one would be ARM_CPU_MITIGATIONS and so on.

This way we can stick all kinds of special mitigations code - not only
speculative execution ones - under those config items and have it all
straight from the get-go.

And I think we should do it now, before it all propagates down the tree
and becomes a lot harder to rename.

Thoughts?

Thx.

-- 
Regards/Gruss,
    Boris.

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

On Fri, Apr 19, 2024, Borislav Petkov wrote:
> On Tue, Apr 16, 2024 at 05:15:07PM -0700, Sean Christopherson wrote:
> > Explicitly disallow enabling mitigations at runtime for kernels that were
> > built with CONFIG_CPU_MITIGATIONS=n, which currently is possible only on
> > x86 (via x86's SPECULATION_MITIGATIONS menuconfig).
> 
> Hm, so the umbrella term is CPU_MITIGATIONS, the x86-one is
> SPECULATION_MITIGATIONS.
> 
> I wanna streamline our namespacing and say, the arch agnostic term
> should be CPU_MITIGATIONS and the x86 one should be then
> X86_CPU_MITIGATIONS, the Arm one would be ARM_CPU_MITIGATIONS and so on.

+1.  That would help avoid goofs like mine.  Maybe.  :-)

> This way we can stick all kinds of special mitigations code - not only
> speculative execution ones - under those config items and have it all
> straight from the get-go.
> 
> And I think we should do it now, before it all propagates down the tree
> and becomes a lot harder to rename.
> 
> Thoughts?
> 
> Thx.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette