[PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[David Kaplan]

When retbleed mitigation is disabled, the kernel already prints an info
message that the system is vulnerable.  Recent code restructuring also
inadvertently led to RETBLEED_INTEL_MSG being printed as an error, which is
unnecessary as retbleed mitigation was already explicitly disabled (by
config option, cmdline, etc.).

Qualify this print statement so the warning is not printed unless an actual
retbleed mitigation was selected and is being disabled due to
incompatibility with spectre_v2.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220624
Signed-off-by: David Kaplan <david.kaplan@amd.com>
---
 arch/x86/kernel/cpu/bugs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 6a526ae1fe99..e08de5b0d20b 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1463,7 +1463,9 @@ static void __init retbleed_update_mitigation(void)
 			break;
 		default:
 			if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) {
-				pr_err(RETBLEED_INTEL_MSG);
+				if (retbleed_mitigation != RETBLEED_MITIGATION_NONE)
+					pr_err(RETBLEED_INTEL_MSG);
+
 				retbleed_mitigation = RETBLEED_MITIGATION_NONE;
 			}
 		}

base-commit: d501f68c45ee1505c4a94c68051387ffa32c9a21
-- 
2.34.1

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Fri, Oct 03, 2025 at 12:19:36PM -0500, David Kaplan wrote:
> When retbleed mitigation is disabled, the kernel already prints an info
> message that the system is vulnerable.  Recent code restructuring also
> inadvertently led to RETBLEED_INTEL_MSG being printed as an error, which is
> unnecessary as retbleed mitigation was already explicitly disabled (by
> config option, cmdline, etc.).
> 
> Qualify this print statement so the warning is not printed unless an actual
> retbleed mitigation was selected and is being disabled due to
> incompatibility with spectre_v2.
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220624
> Signed-off-by: David Kaplan <david.kaplan@amd.com>
> ---
>  arch/x86/kernel/cpu/bugs.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 6a526ae1fe99..e08de5b0d20b 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -1463,7 +1463,9 @@ static void __init retbleed_update_mitigation(void)
>  			break;
>  		default:
>  			if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) {
> -				pr_err(RETBLEED_INTEL_MSG);
> +				if (retbleed_mitigation != RETBLEED_MITIGATION_NONE)
> +					pr_err(RETBLEED_INTEL_MSG);
> +
>  				retbleed_mitigation = RETBLEED_MITIGATION_NONE;
>  			}
>  		}

I guess we can do that for now...

But even with it, my random guest says:

[    0.420377] mitigations: Enabled attack vectors: SMT mitigations: off
[    0.421355] Speculative Store Bypass: Vulnerable
[    0.422234] Spectre V2 : Vulnerable
[    0.422845] Speculative Return Stack Overflow: Vulnerable
[    0.423759] Spectre V1 : Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers

during boot with

# CONFIG_CPU_MITIGATIONS is not set

in its config. 

The "Enabled attack vectors" doesn't mean a whole lot if we've disabled
mitigations. It probably is even a bit misleading.

The others are perhaps *technically* correct but then we're reporting only
a subset of the mitigations and not all for which the machine is affected.

But it ain't the right fix long term, AFAICT.

Because we probably should do this instead:

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 2f8a58ef690e..c789286a480b 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -22,7 +22,7 @@ obj-y                 += topology_common.o topology_ext.o topology_amd.o
 obj-y                  += common.o
 obj-y                  += rdrand.o
 obj-y                  += match.o
-obj-y                  += bugs.o
+obj-$(CONFIG_CPU_MITIGATIONS)          += bugs.o
 obj-y                  += aperfmperf.o
 obj-y                  += cpuid-deps.o cpuid_0x2_table.o
 obj-y                  += umwait.o

because off means off and there should be nothing in the boot log about any
mitigations and no code should be built in. Which is done now - just the code
is inactive which is not what we do with disabled code in the kernel.

But that then causes at least this:

ERROR: modpost: "cpu_buf_vm_clear" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "switch_vcpu_ibpb" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "gds_ucode_mitigated" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "l1tf_vmx_mitigation" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "x86_ibpb_exit_to_user" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "itlb_multihit_kvm_mitigation" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "x86_spec_ctrl_current" [arch/x86/kvm/kvm-amd.ko] undefined!
ERROR: modpost: "x86_virt_spec_ctrl" [arch/x86/kvm/kvm-amd.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
make[1]: *** [/mnt/k/kernel/r/11/linux/Makefile:1960: modpost] Error 2

which means untangling from kvm... which means ugly ifdeffery...

Sounds like a longer project...

Thx.

-- 
Regards/Gruss,
    Boris.

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

RE: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@alien8.de>
> Sent: Monday, October 6, 2025 8:11 AM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>; Peter Zijlstra <peterz@infradead.org>;
> Josh Poimboeuf <jpoimboe@kernel.org>; Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com>; Ingo Molnar <mingo@redhat.com>; Dave
> Hansen <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> <hpa@zytor.com>; Klaus Kusche <klaus.kusche@computerix.info>; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Fri, Oct 03, 2025 at 12:19:36PM -0500, David Kaplan wrote:
> > When retbleed mitigation is disabled, the kernel already prints an info
> > message that the system is vulnerable.  Recent code restructuring also
> > inadvertently led to RETBLEED_INTEL_MSG being printed as an error, which is
> > unnecessary as retbleed mitigation was already explicitly disabled (by
> > config option, cmdline, etc.).
> >
> > Qualify this print statement so the warning is not printed unless an actual
> > retbleed mitigation was selected and is being disabled due to
> > incompatibility with spectre_v2.
> >
> > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220624
> > Signed-off-by: David Kaplan <david.kaplan@amd.com>
> > ---
> >  arch/x86/kernel/cpu/bugs.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index 6a526ae1fe99..e08de5b0d20b 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -1463,7 +1463,9 @@ static void __init retbleed_update_mitigation(void)
> >                       break;
> >               default:
> >                       if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) {
> > -                             pr_err(RETBLEED_INTEL_MSG);
> > +                             if (retbleed_mitigation != RETBLEED_MITIGATION_NONE)
> > +                                     pr_err(RETBLEED_INTEL_MSG);
> > +
> >                               retbleed_mitigation = RETBLEED_MITIGATION_NONE;
> >                       }
> >               }
>
> I guess we can do that for now...
>
> But even with it, my random guest says:
>
> [    0.420377] mitigations: Enabled attack vectors: SMT mitigations: off
> [    0.421355] Speculative Store Bypass: Vulnerable
> [    0.422234] Spectre V2 : Vulnerable
> [    0.422845] Speculative Return Stack Overflow: Vulnerable
> [    0.423759] Spectre V1 : Vulnerable: __user pointer sanitization and usercopy
> barriers only; no swapgs barriers
>
> during boot with
>
> # CONFIG_CPU_MITIGATIONS is not set
>
> in its config.

All of the above messages are printed as pr_info() though, while the RETBLEED_INTEL_MSG was printed as pr_err().  Which I think is an important distinction.

>
> The "Enabled attack vectors" doesn't mean a whole lot if we've disabled
> mitigations. It probably is even a bit misleading.

We could fix that to print None or something like that if none are selected I suppose.

>
> The others are perhaps *technically* correct but then we're reporting only
> a subset of the mitigations and not all for which the machine is affected.
>
> But it ain't the right fix long term, AFAICT.
>
> Because we probably should do this instead:
>
> diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
> index 2f8a58ef690e..c789286a480b 100644
> --- a/arch/x86/kernel/cpu/Makefile
> +++ b/arch/x86/kernel/cpu/Makefile
> @@ -22,7 +22,7 @@ obj-y                 += topology_common.o topology_ext.o
> topology_amd.o
>  obj-y                  += common.o
>  obj-y                  += rdrand.o
>  obj-y                  += match.o
> -obj-y                  += bugs.o
> +obj-$(CONFIG_CPU_MITIGATIONS)          += bugs.o
>  obj-y                  += aperfmperf.o
>  obj-y                  += cpuid-deps.o cpuid_0x2_table.o
>  obj-y                  += umwait.o
>
> because off means off and there should be nothing in the boot log about any
> mitigations and no code should be built in. Which is done now - just the code
> is inactive which is not what we do with disabled code in the kernel.
>
> But that then causes at least this:
>
> ERROR: modpost: "cpu_buf_vm_clear" [arch/x86/kvm/kvm.ko] undefined!
> ERROR: modpost: "switch_vcpu_ibpb" [arch/x86/kvm/kvm.ko] undefined!
> ERROR: modpost: "gds_ucode_mitigated" [arch/x86/kvm/kvm.ko] undefined!
> ERROR: modpost: "l1tf_vmx_mitigation" [arch/x86/kvm/kvm.ko] undefined!
> ERROR: modpost: "x86_ibpb_exit_to_user" [arch/x86/kvm/kvm.ko] undefined!
> ERROR: modpost: "itlb_multihit_kvm_mitigation" [arch/x86/kvm/kvm.ko] undefined!
> ERROR: modpost: "x86_spec_ctrl_current" [arch/x86/kvm/kvm-amd.ko] undefined!
> ERROR: modpost: "x86_virt_spec_ctrl" [arch/x86/kvm/kvm-amd.ko] undefined!
> make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> make[1]: *** [/mnt/k/kernel/r/11/linux/Makefile:1960: modpost] Error 2
>
> which means untangling from kvm... which means ugly ifdeffery...
>
> Sounds like a longer project...
>

Sounds rather yucky.  What about just not calling cpu_select_mitigations() if CONFIG_CPU_MITIGATIONS=n?  Then you won't get any print messages either I'd think.

--David Kaplan

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Mon, Oct 06, 2025 at 01:58:55PM +0000, Kaplan, David wrote:
> Sounds rather yucky. 

I'll give it a try at some point and see how ugly it becomes...

> What about just not calling cpu_select_mitigations() if
> CONFIG_CPU_MITIGATIONS=n?  Then you won't get any print messages either I'd
> think.

I want to not compile in that code at all if CPU_MITIGATIONS=off, actually.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Pawan Gupta]

On Mon, Oct 06, 2025 at 04:04:42PM +0200, Borislav Petkov wrote:
> On Mon, Oct 06, 2025 at 01:58:55PM +0000, Kaplan, David wrote:
> > Sounds rather yucky. 
> 
> I'll give it a try at some point and see how ugly it becomes...
> 
> > What about just not calling cpu_select_mitigations() if
> > CONFIG_CPU_MITIGATIONS=n?  Then you won't get any print messages either I'd
> > think.
> 
> I want to not compile in that code at all if CPU_MITIGATIONS=off, actually.

Even when CPU mitigations are disabled there is still some handling
required for mitigations like GDS that requires a write to MSR to ensure
correct behavior. So not all of bugs.c can be compiled out easily.

IMO, rather than targeting the mitigation enabling code it might make more
sense to compile out the actual mitigations scattered accross the kernel.
This may also improve performance by reducing the code footprint, and can
also help getting a cleaner disassembly.

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Tue, Oct 07, 2025 at 11:22:57AM -0700, Pawan Gupta wrote:
> Even when CPU mitigations are disabled there is still some handling
> required for mitigations like GDS that requires a write to MSR to ensure
> correct behavior.

When mitigations are compiled out there are no mitigations by definition. So
whatever you're talking about must be something else which should happen in
vendor code.

> IMO, rather than targeting the mitigation enabling code it might make more
> sense to compile out the actual mitigations scattered accross the kernel.
> This may also improve performance by reducing the code footprint, and can
> also help getting a cleaner disassembly.

Probably... however, it needs to be done smartly because sprinkling ifdeffery
and turning what is an already unreadable mess into a bigger abomination,
won't fly. Perhaps split out the mitigations glue into separate compilation
units and build-disable them... we'll see.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Pawan Gupta]

On Wed, Oct 08, 2025 at 12:12:29AM +0200, Borislav Petkov wrote:
> On Tue, Oct 07, 2025 at 11:22:57AM -0700, Pawan Gupta wrote:
> > Even when CPU mitigations are disabled there is still some handling
> > required for mitigations like GDS that requires a write to MSR to ensure
> > correct behavior.
> 
> When mitigations are compiled out there are no mitigations by definition.

GDS microcode mitigation is enabled by default, for disabling the
mitigation an MSR write is required.

> So whatever you're talking about must be something else which should
> happen in vendor code.

Perhaps yes when bugs.c is compiled out.

> > IMO, rather than targeting the mitigation enabling code it might make more
> > sense to compile out the actual mitigations scattered accross the kernel.
> > This may also improve performance by reducing the code footprint, and can
> > also help getting a cleaner disassembly.
> 
> Probably... however, it needs to be done smartly because sprinkling ifdeffery
> and turning what is an already unreadable mess into a bigger abomination,
> won't fly. Perhaps split out the mitigations glue into separate compilation
> units and build-disable them... we'll see.

Ya, that would be better.

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Josh Poimboeuf]

On Tue, Oct 07, 2025 at 04:08:21PM -0700, Pawan Gupta wrote:
> On Wed, Oct 08, 2025 at 12:12:29AM +0200, Borislav Petkov wrote:
> > On Tue, Oct 07, 2025 at 11:22:57AM -0700, Pawan Gupta wrote:
> > > IMO, rather than targeting the mitigation enabling code it might make more
> > > sense to compile out the actual mitigations scattered accross the kernel.
> > > This may also improve performance by reducing the code footprint, and can
> > > also help getting a cleaner disassembly.

Isn't that what CONFIG_CPU_MITIGATIONS=n already does today?

> > Probably... however, it needs to be done smartly because sprinkling ifdeffery
> > and turning what is an already unreadable mess into a bigger abomination,
> > won't fly. Perhaps split out the mitigations glue into separate compilation
> > units and build-disable them... we'll see.
> 
> Ya, that would be better.

On a sort of related note, it's confusing that there are two completely
different classes of MITIGATION options which get conflated:

1) compile the kernel with support for certain mitigations:

    MITIGATION_RETPOLINE
    MITIGATION_RETHUNK
    MITIGATION_PAGE_TABLE_ISOLATION
    MITIGATION_UNRET_ENTRY
    MITIGATION_CALL_DEPTH_TRACKING
    MITIGATION_IBPB_ENTRY
    MITIGATION_IBRS_ENTRY
    MITIGATION_SRSO
    MITIGATION_SLS

2) enable bug-specific runtime defaults:

    MITIGATION_GDS
    MITIGATION_RFDS
    MITIGATION_SPECTRE_BHI
    MITIGATION_MDS
    MITIGATION_TAA
    MITIGATION_MMIO_STALE_DATA
    MITIGATION_L1TF
    MITIGATION_RETBLEED
    MITIGATION_SPECTRE_V1
    MITIGATION_SPECTRE_V2
    MITIGATION_SRBDS
    MITIGATION_SSB
    MITIGATION_ITS
    MITIGATION_TSA
    MITIGATION_VMSCAPE

In general, #1 uglify the kernel.  And some #2 depend on #1.

IMO, we should rename the #1 options.  For example:

  MITIGATION_RETPOLINE -> X86_UGLY_INDIRECT_THUNKS
  MITIGATION_RETHUNK   -> X86_UGLY_RETURN_THUNKS

  etc...

Then one only needs to grep their .config file for UGLY to understand
why their disassembly is so inscrutable ;-)

-- 
Josh

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Tue, Oct 07, 2025 at 05:14:29PM -0700, Josh Poimboeuf wrote:
> Isn't that what CONFIG_CPU_MITIGATIONS=n already does today?

I'd like =n to mean, code is not compiled in.

We do have some savings:

   text	   data	    bss	    dec	    hex	filename
136442490	9737118		36764336	182943944	ae780c8	vmlinux 	# CONFIG_CPU_MITIGATIONS is not set
138493310	10692818	37741668	186927796	b244ab4	vmlinux		# CONFIG_CPU_MITIGATIONS=y

but look at bugs.o:

# CONFIG_CPU_MITIGATIONS is not set	599K arch/x86/kernel/cpu/bugs.o
# CONFIG_CPU_MITIGATIONS=y		625K arch/x86/kernel/cpu/bugs.o

and those unused 600K still go into vmlinux:

$ readelf -W -s vmlinux | grep cpu_show_
 38058: ffffffff81869d20    27 FUNC    LOCAL  DEFAULT    1 cpu_show_not_affected
 91642: ffffffff81284980    70 FUNC    GLOBAL DEFAULT    1 cpu_show_vmscape
 92944: ffffffff812840f0    68 FUNC    GLOBAL DEFAULT    1 cpu_show_spectre_v1
 93449: ffffffff812847e0    70 FUNC    GLOBAL DEFAULT    1 cpu_show_gds
 96967: ffffffff81869d20    27 FUNC    WEAK   DEFAULT    1 cpu_show_ghostwrite
 99329: ffffffff812843b0    70 FUNC    GLOBAL DEFAULT    1 cpu_show_spec_store_bypass
102119: ffffffff81284830    70 FUNC    GLOBAL DEFAULT    1 cpu_show_reg_file_data_sampling
102618: ffffffff812845b0    56 FUNC    GLOBAL DEFAULT    1 cpu_show_itlb_multihit
102660: ffffffff81284880    85 FUNC    GLOBAL DEFAULT    1 cpu_show_old_microcode
103154: ffffffff812848e0    70 FUNC    GLOBAL DEFAULT    1 cpu_show_indirect_target_selection
103474: ffffffff81284460   164 FUNC    GLOBAL DEFAULT    1 cpu_show_mds
103673: ffffffff81284510   153 FUNC    GLOBAL DEFAULT    1 cpu_show_tsx_async_abort
106613: ffffffff81284930    70 FUNC    GLOBAL DEFAULT    1 cpu_show_tsa
109692: ffffffff81284400    92 FUNC    GLOBAL DEFAULT    1 cpu_show_l1tf
111021: ffffffff81284640   150 FUNC    GLOBAL DEFAULT    1 cpu_show_mmio_stale_data
111165: ffffffff812845f0    70 FUNC    GLOBAL DEFAULT    1 cpu_show_srbds
112332: ffffffff81284090    83 FUNC    GLOBAL DEFAULT    1 cpu_show_meltdown
114213: ffffffff812846e0   174 FUNC    GLOBAL DEFAULT    1 cpu_show_retbleed
114312: ffffffff81284790    70 FUNC    GLOBAL DEFAULT    1 cpu_show_spec_rstack_overflow
118586: ffffffff81284140   619 FUNC    GLOBAL DEFAULT    1 cpu_show_spectre_v2

$ readelf -W -s vmlinux | grep _parse_cmdline
  2575: ffffffff897a0050    27 FUNC    LOCAL  DEFAULT   18 nospectre_v2_parse_cmdline
  2578: ffffffff897a0070    27 FUNC    LOCAL  DEFAULT   18 nossb_parse_cmdline
  2587: ffffffff897a0110    37 FUNC    LOCAL  DEFAULT   18 its_parse_cmdline
  2591: ffffffff897a01d0   138 FUNC    LOCAL  DEFAULT   18 tsx_async_abort_parse_cmdline
  2594: ffffffff897a0260   138 FUNC    LOCAL  DEFAULT   18 mmio_stale_data_parse_cmdline
  2597: ffffffff897a02f0    97 FUNC    LOCAL  DEFAULT   18 rfds_parse_cmdline
  2599: ffffffff897a0360    56 FUNC    LOCAL  DEFAULT   18 srbds_parse_cmdline
  2601: ffffffff897a03a0    38 FUNC    LOCAL  DEFAULT   18 l1d_flush_parse_cmdline
  2603: ffffffff897a03d0    96 FUNC    LOCAL  DEFAULT   18 gds_parse_cmdline
  2604: ffffffff897a0430   166 FUNC    LOCAL  DEFAULT   18 tsa_parse_cmdline
  2606: ffffffff897a04e0   268 FUNC    LOCAL  DEFAULT   18 spectre_v2_user_parse_cmdline
  2608: ffffffff897a05f0   487 FUNC    LOCAL  DEFAULT   18 spectre_v2_parse_cmdline
  2609: ffffffff897a07e0   131 FUNC    LOCAL  DEFAULT   18 spectre_bhi_parse_cmdline
  2611: ffffffff897a0870   206 FUNC    LOCAL  DEFAULT   18 ssb_parse_cmdline
  2613: ffffffff897a0a30   200 FUNC    LOCAL  DEFAULT   18 srso_parse_cmdline
  2615: ffffffff897a0b00   178 FUNC    LOCAL  DEFAULT   18 vmscape_parse_cmdline
  2617: ffffffff897a0bc0   344 FUNC    LOCAL  DEFAULT   18 retbleed_parse_cmdline

and so on...

So I'd like to try to see whether completely axing it off in the =n case
without incurring a lot of ugly ifdeffery, would work.

> Then one only needs to grep their .config file for UGLY to understand
> why their disassembly is so inscrutable ;-)

Not sure about UGLY but if you can come up with a name that says "has impact
on the resulting code and when you have them enabled, you have weird asm
constructs all over the place", sure, why not.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Josh Poimboeuf]

On Wed, Oct 08, 2025 at 12:21:36PM +0200, Borislav Petkov wrote:
> On Tue, Oct 07, 2025 at 05:14:29PM -0700, Josh Poimboeuf wrote:
> > Isn't that what CONFIG_CPU_MITIGATIONS=n already does today?
> 
> I'd like =n to mean, code is not compiled in.
> 
> We do have some savings:
> 
>    text	   data	    bss	    dec	    hex	filename
> 136442490	9737118		36764336	182943944	ae780c8	vmlinux 	# CONFIG_CPU_MITIGATIONS is not set
> 138493310	10692818	37741668	186927796	b244ab4	vmlinux		# CONFIG_CPU_MITIGATIONS=y
> 
> but look at bugs.o:
> 
> # CONFIG_CPU_MITIGATIONS is not set	599K arch/x86/kernel/cpu/bugs.o
> # CONFIG_CPU_MITIGATIONS=y		625K arch/x86/kernel/cpu/bugs.o

The good news is that CONFIG_CPU_MITIGATIONS=n already seems to remove
all the "ugly", but yeah, stripping out bugs.o would be a nice bonus.

> > Then one only needs to grep their .config file for UGLY to understand
> > why their disassembly is so inscrutable ;-)
> 
> Not sure about UGLY but if you can come up with a name that says "has impact
> on the resulting code and when you have them enabled, you have weird asm
> constructs all over the place", sure, why not.

I think almost anything which removes the "MITIGATION" from the name
would be an improvement.  The build enablements really are a different
kind of thing compared to the runtime defaults and it's confusing to
intermingle them together.

The "UGLY" was tongue in cheek, but it does have a nice ring to it.

Maybe CONFIG_BUILD_INDIRECT_THUNKS or so.

-- 
Josh

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Pawan Gupta]

On Tue, Oct 07, 2025 at 05:14:29PM -0700, Josh Poimboeuf wrote:
> On Tue, Oct 07, 2025 at 04:08:21PM -0700, Pawan Gupta wrote:
> > On Wed, Oct 08, 2025 at 12:12:29AM +0200, Borislav Petkov wrote:
> > > On Tue, Oct 07, 2025 at 11:22:57AM -0700, Pawan Gupta wrote:
> > > > IMO, rather than targeting the mitigation enabling code it might make more
> > > > sense to compile out the actual mitigations scattered accross the kernel.
> > > > This may also improve performance by reducing the code footprint, and can
> > > > also help getting a cleaner disassembly.
> 
> Isn't that what CONFIG_CPU_MITIGATIONS=n already does today?

Not entirely, looking at entry_64.o for example, I see 243 NOPs with
CONFIG_CPU_MITIGATIONS=n. I suspect a lot of them are due to ALTERNATIVEs
for mitigations. In the same file, clear_bhb_loop() is not compliled out
and adds ~160 bytes.

Another example is process.c which still contains below functions:

0000000000000000 <speculation_ctrl_update_tif>:
00000000000008b0 <speculative_store_bypass_ht_init>:
0000000000000980 <speculation_ctrl_update>:
0000000000000c30 <speculation_ctrl_update_current>:

> > > Probably... however, it needs to be done smartly because sprinkling ifdeffery
> > > and turning what is an already unreadable mess into a bigger abomination,
> > > won't fly. Perhaps split out the mitigations glue into separate compilation
> > > units and build-disable them... we'll see.
> > 
> > Ya, that would be better.
> 
> On a sort of related note, it's confusing that there are two completely
> different classes of MITIGATION options which get conflated:
> 
> 1) compile the kernel with support for certain mitigations:
> 
>     MITIGATION_RETPOLINE
>     MITIGATION_RETHUNK
>     MITIGATION_PAGE_TABLE_ISOLATION
>     MITIGATION_UNRET_ENTRY
>     MITIGATION_CALL_DEPTH_TRACKING
>     MITIGATION_IBPB_ENTRY
>     MITIGATION_IBRS_ENTRY
>     MITIGATION_SRSO
>     MITIGATION_SLS
> 
> 2) enable bug-specific runtime defaults:
> 
>     MITIGATION_GDS
>     MITIGATION_RFDS
>     MITIGATION_SPECTRE_BHI
>     MITIGATION_MDS
>     MITIGATION_TAA
>     MITIGATION_MMIO_STALE_DATA
>     MITIGATION_L1TF
>     MITIGATION_RETBLEED
>     MITIGATION_SPECTRE_V1
>     MITIGATION_SPECTRE_V2
>     MITIGATION_SRBDS
>     MITIGATION_SSB
>     MITIGATION_ITS
>     MITIGATION_TSA
>     MITIGATION_VMSCAPE
> 
> In general, #1 uglify the kernel.  And some #2 depend on #1.
> 
> IMO, we should rename the #1 options.  For example:
> 
>   MITIGATION_RETPOLINE -> X86_UGLY_INDIRECT_THUNKS
>   MITIGATION_RETHUNK   -> X86_UGLY_RETURN_THUNKS
> 
>   etc...
> 
> Then one only needs to grep their .config file for UGLY to understand
> why their disassembly is so inscrutable ;-)

:-) Agree, this is ugly. One way to handle this could be two levels of
Kconfig options like below:

* CONFIG_MITIGATION_FOO			- Compiles out the mitigation
  * CONFIG_MITIGATION_FOO_DEFAULT	- Sets the bootup default
  select X86_UGLY_INDIRECT_THUNKS

Then supporting mitigation like INDIRECT_THUNKS would only be enabled if
there is a dependent mitigation enabled.

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Pawan Gupta]

On Wed, Oct 08, 2025 at 12:21:36PM +0200, Borislav Petkov wrote:
> On Tue, Oct 07, 2025 at 05:14:29PM -0700, Josh Poimboeuf wrote:
> > Isn't that what CONFIG_CPU_MITIGATIONS=n already does today?
> 
> I'd like =n to mean, code is not compiled in.
> 
> We do have some savings:
> 
>    text	   data	    bss	    dec	    hex	filename
> 136442490	9737118		36764336	182943944	ae780c8	vmlinux 	# CONFIG_CPU_MITIGATIONS is not set
> 138493310	10692818	37741668	186927796	b244ab4	vmlinux		# CONFIG_CPU_MITIGATIONS=y

I guess bulk of these savings are comming from CALL_THUNKS that force 16
byte function alignment.

> but look at bugs.o:
> 
> # CONFIG_CPU_MITIGATIONS is not set	599K arch/x86/kernel/cpu/bugs.o
> # CONFIG_CPU_MITIGATIONS=y		625K arch/x86/kernel/cpu/bugs.o
> 
> and those unused 600K still go into vmlinux:

Thats a lot. OTOH, most of the bugs.c is __init code, do you think it is
still problematic?

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Wed, Oct 08, 2025 at 11:04:32PM -0700, Pawan Gupta wrote:
> Thats a lot. OTOH, most of the bugs.c is __init code, do you think it is
> still problematic?

What is wrong with aiming to not have dead code in the kernel if it can be
removed cleanly?

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Wed, Oct 08, 2025 at 06:07:02PM -0700, Josh Poimboeuf wrote:
> I think almost anything which removes the "MITIGATION" from the name
> would be an improvement.  The build enablements really are a different
> kind of thing compared to the runtime defaults and it's confusing to
> intermingle them together.
> 
> The "UGLY" was tongue in cheek, but it does have a nice ring to it.
> 
> Maybe CONFIG_BUILD_INDIRECT_THUNKS or so.

Right, makes sense.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Pawan Gupta]

On Thu, Oct 09, 2025 at 12:15:57PM +0200, Borislav Petkov wrote:
> On Wed, Oct 08, 2025 at 11:04:32PM -0700, Pawan Gupta wrote:
> > Thats a lot. OTOH, most of the bugs.c is __init code, do you think it is
> > still problematic?
> 
> What is wrong with aiming to not have dead code in the kernel if it can be
> removed cleanly?

Nothing wrong with that. There are certain things (like I mentioned
earlier) that needs to be moved out of bugs.c.

RE: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Sent: Thursday, October 9, 2025 12:14 PM
> To: Borislav Petkov <bp@alien8.de>
> Cc: Josh Poimboeuf <jpoimboe@kernel.org>; Kaplan, David
> <David.Kaplan@amd.com>; Thomas Gleixner <tglx@linutronix.de>; Peter Zijlstra
> <peterz@infradead.org>; Ingo Molnar <mingo@redhat.com>; Dave Hansen
> <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> <hpa@zytor.com>; Klaus Kusche <klaus.kusche@computerix.info>; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Oct 09, 2025 at 12:15:57PM +0200, Borislav Petkov wrote:
> > On Wed, Oct 08, 2025 at 11:04:32PM -0700, Pawan Gupta wrote:
> > > Thats a lot. OTOH, most of the bugs.c is __init code, do you think it is
> > > still problematic?
> >
> > What is wrong with aiming to not have dead code in the kernel if it can be
> > removed cleanly?
>
> Nothing wrong with that. There are certain things (like I mentioned
> earlier) that needs to be moved out of bugs.c.

If we really want to optimize a CONFIG_CPU_MITIGATIONS=n kernel, why not also look at alternatives that will never be enabled?

All the extra NOPs I think can affect performance in various ways and if there was a way at compile time to know that the alternative would never be enabled (because the feature is completely dependent on a cpu mitigation) you could eliminate the NOPs...

--David Kaplan

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Thu, Oct 09, 2025 at 06:13:20PM +0000, Kaplan, David wrote:
> If we really want to optimize a CONFIG_CPU_MITIGATIONS=n kernel, why not
> also look at alternatives that will never be enabled?
> 
> All the extra NOPs I think can affect performance in various ways and if
> there was a way at compile time to know that the alternative would never be
> enabled (because the feature is completely dependent on a cpu mitigation)
> you could eliminate the NOPs...

I don't see why not. That mitigations gunk should be just like any other
CONFIG_-controllable item and not simply "leak" into the build because, oh
well, we've done it this way from the very beginning and no one should touch
it.

So yeah, eventually we should try this. I've been experimenting with
untangling bugs.c today, will check how much it actually saves us when
I finish beating the stinking pile into submission.

-- 
Regards/Gruss,
    Boris.

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

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Josh Poimboeuf]

On Wed, Oct 08, 2025 at 10:33:36PM -0700, Pawan Gupta wrote:
> On Tue, Oct 07, 2025 at 05:14:29PM -0700, Josh Poimboeuf wrote:
> > On Tue, Oct 07, 2025 at 04:08:21PM -0700, Pawan Gupta wrote:
> >   MITIGATION_RETPOLINE -> X86_UGLY_INDIRECT_THUNKS
> >   MITIGATION_RETHUNK   -> X86_UGLY_RETURN_THUNKS
> > 
> >   etc...
> > 
> > Then one only needs to grep their .config file for UGLY to understand
> > why their disassembly is so inscrutable ;-)
> 
> :-) Agree, this is ugly. One way to handle this could be two levels of
> Kconfig options like below:
> 
> * CONFIG_MITIGATION_FOO			- Compiles out the mitigation

Maybe, though compiling out individual features would be complicated by
the fact that we have dependencies between several of the mitigations,
as evidenced by *_update_mitigation().

>   * CONFIG_MITIGATION_FOO_DEFAULT	- Sets the bootup default

I'm wondering if we can just get rid of the compiled-in defaults.  Do
people really need that anymore, now that we have the attack vector
controls?  We could instead have

  CONFIG_CPU_MITIGATIONS_OFF
  CONFIG_CPU_MITIGATIONS_AUTO
  CONFIG_CPU_MITIGATIONS_AUTO_NOSMT

  CONFIG_CPU_MITIGATIONS_USER_USER
  CONFIG_CPU_MITIGATIONS_USER_KERNEL
  CONFIG_CPU_MITIGATIONS_GUEST_HOST
  CONFIG_CPU_MITIGATIONS_GUEST_GUEST

... which should cover the main cases.  And of course there's always
CONFIG_CMDLINE for more customization.

>   select X86_UGLY_INDIRECT_THUNKS

Unfortunately it's not always straightforward enough to say "mitigation
FOO always needs X ugly feature".

For example, newer CPUs mitigate Spectre v2 with enhanced IBRS, so they
don't necessarily need all the retpoline and legacy IBRS stuff.  So
CONFIG_MITIGATION_SPECTRE_V2 shouldn't enable those unconditionally.

Instead, CONFIG_MITIGATION_SPECTRE_V2 could enable a submenu which then
allows the user to enable retpoline, IBRS on entry, etc, with each
having help text describing what generations of CPUs it would be the
default for, to help guide the user to choose sane defaults depending on
their CPU:

  * CONFIG_MITIGATION_SPECTRE_V2
    * CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE
      select CONFIG_BUILD_INDIRECT_THUNKS
    * CONFIG_MITIGATION_SPECTRE_V2_IBRS
      select CONFIG_BUILD_IBRS_ENTRY

-- 
Josh

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Pawan Gupta]

On Thu, Oct 09, 2025 at 06:10:42PM -0700, Josh Poimboeuf wrote:
> On Wed, Oct 08, 2025 at 10:33:36PM -0700, Pawan Gupta wrote:
> > On Tue, Oct 07, 2025 at 05:14:29PM -0700, Josh Poimboeuf wrote:
> > > On Tue, Oct 07, 2025 at 04:08:21PM -0700, Pawan Gupta wrote:
> > >   MITIGATION_RETPOLINE -> X86_UGLY_INDIRECT_THUNKS
> > >   MITIGATION_RETHUNK   -> X86_UGLY_RETURN_THUNKS
> > > 
> > >   etc...
> > > 
> > > Then one only needs to grep their .config file for UGLY to understand
> > > why their disassembly is so inscrutable ;-)
> > 
> > :-) Agree, this is ugly. One way to handle this could be two levels of
> > Kconfig options like below:
> > 
> > * CONFIG_MITIGATION_FOO			- Compiles out the mitigation
> 
> Maybe, though compiling out individual features would be complicated by
> the fact that we have dependencies between several of the mitigations,
> as evidenced by *_update_mitigation().

My thought was separate them out as:

- Generic mitigation like,
  CONFIG_MITIGATION_CLEAR_CPU_BUFFERS
  ...
  which are not directly user selectable.

- Vulnerability based mitigation like,
  CONFIG_MITIGATION_MDS
  CONFIG_MITIGATION_TAA
  CONFIG_MITIGATION_MMIO
  CONFIG_MITIGATION_TSA
  ...
  which are user selectable, and does:
  
    select CONFIG_MITIGATION_CLEAR_CPU_BUFFERS

  When none from this category is selected,
  CONFIG_MITIGATION_CLEAR_CPU_BUFFERS stays unset. All of VERW sites can
  then use CONFIG_MITIGATION_CLEAR_CPU_BUFFERS to not generate NOPs/JMPs as
  well.

> >   * CONFIG_MITIGATION_FOO_DEFAULT	- Sets the bootup default
> 
> I'm wondering if we can just get rid of the compiled-in defaults.  Do
> people really need that anymore, now that we have the attack vector
> controls?  We could instead have
> 
>   CONFIG_CPU_MITIGATIONS_OFF
>   CONFIG_CPU_MITIGATIONS_AUTO
>   CONFIG_CPU_MITIGATIONS_AUTO_NOSMT
> 
>   CONFIG_CPU_MITIGATIONS_USER_USER
>   CONFIG_CPU_MITIGATIONS_USER_KERNEL
>   CONFIG_CPU_MITIGATIONS_GUEST_HOST
>   CONFIG_CPU_MITIGATIONS_GUEST_GUEST
> 
> ... which should cover the main cases.  And of course there's always
> CONFIG_CMDLINE for more customization.

That works too.

> >   select X86_UGLY_INDIRECT_THUNKS
> 
> Unfortunately it's not always straightforward enough to say "mitigation
> FOO always needs X ugly feature".
> 
> For example, newer CPUs mitigate Spectre v2 with enhanced IBRS, so they
> don't necessarily need all the retpoline and legacy IBRS stuff.  So
> CONFIG_MITIGATION_SPECTRE_V2 shouldn't enable those unconditionally.

A more conservative approach can work here that selects a supporting
mitigation even though not all CPUs need it.

> Instead, CONFIG_MITIGATION_SPECTRE_V2 could enable a submenu which then
> allows the user to enable retpoline, IBRS on entry, etc, with each
> having help text describing what generations of CPUs it would be the
> default for, to help guide the user to choose sane defaults depending on
> their CPU:
> 
>   * CONFIG_MITIGATION_SPECTRE_V2
>     * CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE
>       select CONFIG_BUILD_INDIRECT_THUNKS
>     * CONFIG_MITIGATION_SPECTRE_V2_IBRS
>       select CONFIG_BUILD_IBRS_ENTRY

That would be good if a kernel is built for certain specific CPU(s). This
may not be ideal for distro kernels.

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Josh Poimboeuf]

On Fri, Oct 10, 2025 at 11:47:25AM -0700, Pawan Gupta wrote:
> > Instead, CONFIG_MITIGATION_SPECTRE_V2 could enable a submenu which then
> > allows the user to enable retpoline, IBRS on entry, etc, with each
> > having help text describing what generations of CPUs it would be the
> > default for, to help guide the user to choose sane defaults depending on
> > their CPU:
> > 
> >   * CONFIG_MITIGATION_SPECTRE_V2
> >     * CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE
> >       select CONFIG_BUILD_INDIRECT_THUNKS
> >     * CONFIG_MITIGATION_SPECTRE_V2_IBRS
> >       select CONFIG_BUILD_IBRS_ENTRY
> 
> That would be good if a kernel is built for certain specific CPU(s). This
> may not be ideal for distro kernels.

Why not?  A distro can just enable everything:

  CONFIG_MITIGATION_SPECTRE_V2=y
  CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE=y
  CONFIG_MITIGATION_SPECTRE_V2_IBRS=y

and then if/when some older HW ages out of being supported by the
distro, they can start disabling things.

-- 
Josh

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Pawan Gupta]

On Fri, Oct 10, 2025 at 12:19:12PM -0700, Josh Poimboeuf wrote:
> On Fri, Oct 10, 2025 at 11:47:25AM -0700, Pawan Gupta wrote:
> > > Instead, CONFIG_MITIGATION_SPECTRE_V2 could enable a submenu which then
> > > allows the user to enable retpoline, IBRS on entry, etc, with each
> > > having help text describing what generations of CPUs it would be the
> > > default for, to help guide the user to choose sane defaults depending on
> > > their CPU:
> > > 
> > >   * CONFIG_MITIGATION_SPECTRE_V2
> > >     * CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE
> > >       select CONFIG_BUILD_INDIRECT_THUNKS
> > >     * CONFIG_MITIGATION_SPECTRE_V2_IBRS
> > >       select CONFIG_BUILD_IBRS_ENTRY
> > 
> > That would be good if a kernel is built for certain specific CPU(s). This
> > may not be ideal for distro kernels.
> 
> Why not?  A distro can just enable everything:

Ahh, right.

>   CONFIG_MITIGATION_SPECTRE_V2=y
>   CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE=y
>   CONFIG_MITIGATION_SPECTRE_V2_IBRS=y
> 
> and then if/when some older HW ages out of being supported by the
> distro, they can start disabling things.

Yup, that makes sense.

RE: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Josh Poimboeuf <jpoimboe@kernel.org>
> Sent: Friday, October 10, 2025 2:19 PM
> To: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Cc: Borislav Petkov <bp@alien8.de>; Kaplan, David <David.Kaplan@amd.com>;
> Thomas Gleixner <tglx@linutronix.de>; Peter Zijlstra <peterz@infradead.org>; Ingo
> Molnar <mingo@redhat.com>; Dave Hansen <dave.hansen@linux.intel.com>;
> x86@kernel.org; H . Peter Anvin <hpa@zytor.com>; Klaus Kusche
> <klaus.kusche@computerix.info>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Fri, Oct 10, 2025 at 11:47:25AM -0700, Pawan Gupta wrote:
> > > Instead, CONFIG_MITIGATION_SPECTRE_V2 could enable a submenu which
> then
> > > allows the user to enable retpoline, IBRS on entry, etc, with each
> > > having help text describing what generations of CPUs it would be the
> > > default for, to help guide the user to choose sane defaults depending on
> > > their CPU:
> > >
> > >   * CONFIG_MITIGATION_SPECTRE_V2
> > >     * CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE
> > >       select CONFIG_BUILD_INDIRECT_THUNKS
> > >     * CONFIG_MITIGATION_SPECTRE_V2_IBRS
> > >       select CONFIG_BUILD_IBRS_ENTRY
> >
> > That would be good if a kernel is built for certain specific CPU(s). This
> > may not be ideal for distro kernels.
>
> Why not?  A distro can just enable everything:
>
>   CONFIG_MITIGATION_SPECTRE_V2=y
>   CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE=y
>   CONFIG_MITIGATION_SPECTRE_V2_IBRS=y
>
> and then if/when some older HW ages out of being supported by the
> distro, they can start disabling things.
>

Is this really improving things?

There's already a lot of CONFIG options related to mitigations that make testing a pain, and this seems to just make it worse by now having even more options that may or may not make sense together.

I get the value in building a kernel with all mitigations disabled, although frankly I think that only makes sense if it's substantially better than just 'mitigations=off'.  But is the cost of only building support for IBRS and not retpoline really buying much?

--David Kaplan

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Josh Poimboeuf]

On Fri, Oct 10, 2025 at 07:27:22PM +0000, Kaplan, David wrote:
> > On Fri, Oct 10, 2025 at 11:47:25AM -0700, Pawan Gupta wrote:
> > > > Instead, CONFIG_MITIGATION_SPECTRE_V2 could enable a submenu which
> > then
> > > > allows the user to enable retpoline, IBRS on entry, etc, with each
> > > > having help text describing what generations of CPUs it would be the
> > > > default for, to help guide the user to choose sane defaults depending on
> > > > their CPU:
> > > >
> > > >   * CONFIG_MITIGATION_SPECTRE_V2
> > > >     * CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE
> > > >       select CONFIG_BUILD_INDIRECT_THUNKS
> > > >     * CONFIG_MITIGATION_SPECTRE_V2_IBRS
> > > >       select CONFIG_BUILD_IBRS_ENTRY
> > >
> > > That would be good if a kernel is built for certain specific CPU(s). This
> > > may not be ideal for distro kernels.
> >
> > Why not?  A distro can just enable everything:
> >
> >   CONFIG_MITIGATION_SPECTRE_V2=y
> >   CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE=y
> >   CONFIG_MITIGATION_SPECTRE_V2_IBRS=y
> >
> > and then if/when some older HW ages out of being supported by the
> > distro, they can start disabling things.
> >
> 
> Is this really improving things?
> 
> There's already a lot of CONFIG options related to mitigations that
> make testing a pain, and this seems to just make it worse by now
> having even more options that may or may not make sense together.
> 
> I get the value in building a kernel with all mitigations disabled,
> although frankly I think that only makes sense if it's substantially
> better than just 'mitigations=off'.  But is the cost of only building
> support for IBRS and not retpoline really buying much?

I think this would add several improvements.

It makes it clearer *why* retpolines are enabled: to mitigate Spectre v2
for older hardware.  (Though, frustratingly, retpolines have made a
comeback thanks to ITS.)

If I know I won't be running my kernel on old HW, this would make it
easy to phase out old mitigations that are no longer needed, that
otherwise uglify the code and might affect performance even when they're
disabled at runtime.

That would be useful for me personally (I don't want that crap in my
kernel if I don't need it), but also for distros which phase out support
for older CPUs.

Yes, it does add some config options, but we can counterbalance that by
removing all the ones which set the defaults, and instead only allow
changing defaults at the granularity of attack vectors.

And these MITIGATION config options wouldn't need to be referenced by
actual code.  Their purpose would be to select
CONFIG_BUILD_INDIRECT_THUNKS and friends, as needed, which are in a
separate namespace (naming bikeshedding welcome).  So overall I think
there would be a lot less confusion about the purpose of each config
option.

(Yes, CONFIG_MITIGATION_* could also be used to compile out individual
mitigations, but I'm not quite convinced that would be worth all the
ifdeffery)

That's kind of a lot, I can work up some patches to clarify what it all
would look like.

-- 
Josh

RE: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Josh Poimboeuf <jpoimboe@kernel.org>
> Sent: Friday, October 10, 2025 3:48 PM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>; Borislav Petkov
> <bp@alien8.de>; Thomas Gleixner <tglx@linutronix.de>; Peter Zijlstra
> <peterz@infradead.org>; Ingo Molnar <mingo@redhat.com>; Dave Hansen
> <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> <hpa@zytor.com>; Klaus Kusche <klaus.kusche@computerix.info>; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Fri, Oct 10, 2025 at 07:27:22PM +0000, Kaplan, David wrote:
> > > On Fri, Oct 10, 2025 at 11:47:25AM -0700, Pawan Gupta wrote:
> > > > > Instead, CONFIG_MITIGATION_SPECTRE_V2 could enable a submenu
> which
> > > then
> > > > > allows the user to enable retpoline, IBRS on entry, etc, with each
> > > > > having help text describing what generations of CPUs it would be the
> > > > > default for, to help guide the user to choose sane defaults depending on
> > > > > their CPU:
> > > > >
> > > > >   * CONFIG_MITIGATION_SPECTRE_V2
> > > > >     * CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE
> > > > >       select CONFIG_BUILD_INDIRECT_THUNKS
> > > > >     * CONFIG_MITIGATION_SPECTRE_V2_IBRS
> > > > >       select CONFIG_BUILD_IBRS_ENTRY
> > > >
> > > > That would be good if a kernel is built for certain specific CPU(s). This
> > > > may not be ideal for distro kernels.
> > >
> > > Why not?  A distro can just enable everything:
> > >
> > >   CONFIG_MITIGATION_SPECTRE_V2=y
> > >   CONFIG_MITIGATION_SPECTRE_V2_RETPOLINE=y
> > >   CONFIG_MITIGATION_SPECTRE_V2_IBRS=y
> > >
> > > and then if/when some older HW ages out of being supported by the
> > > distro, they can start disabling things.
> > >
> >
> > Is this really improving things?
> >
> > There's already a lot of CONFIG options related to mitigations that
> > make testing a pain, and this seems to just make it worse by now
> > having even more options that may or may not make sense together.
> >
> > I get the value in building a kernel with all mitigations disabled,
> > although frankly I think that only makes sense if it's substantially
> > better than just 'mitigations=off'.  But is the cost of only building
> > support for IBRS and not retpoline really buying much?
>
> I think this would add several improvements.
>
> It makes it clearer *why* retpolines are enabled: to mitigate Spectre v2
> for older hardware.  (Though, frustratingly, retpolines have made a
> comeback thanks to ITS.)

I don't think you mean 'enabled' here, you mean why they're being built into the kernel?  If retpolines are being enabled at runtime, that is reported via sysfs.

>
> If I know I won't be running my kernel on old HW, this would make it
> easy to phase out old mitigations that are no longer needed, that
> otherwise uglify the code and might affect performance even when they're
> disabled at runtime.

To check if I'm understanding right, is the idea that if you have an ALTERNATIVE that is based on some feature flag (like X86_FEATURE_CLEAR_CPU_BUF) but your kernel is built without any support for those mitigations that need that then that macro would essentially get deleted at compile time so you don't have the extra NOPs?  That seems useful.

And if you don't need any retpoline support then you remove retpolines from your compile options?

>
> That would be useful for me personally (I don't want that crap in my
> kernel if I don't need it), but also for distros which phase out support
> for older CPUs.
>
> Yes, it does add some config options, but we can counterbalance that by
> removing all the ones which set the defaults, and instead only allow
> changing defaults at the granularity of attack vectors.

I agree that would simplify things

>
> And these MITIGATION config options wouldn't need to be referenced by
> actual code.  Their purpose would be to select
> CONFIG_BUILD_INDIRECT_THUNKS and friends, as needed, which are in a
> separate namespace (naming bikeshedding welcome).  So overall I think
> there would be a lot less confusion about the purpose of each config
> option.
>
> (Yes, CONFIG_MITIGATION_* could also be used to compile out individual
> mitigations, but I'm not quite convinced that would be worth all the
> ifdeffery)
>
> That's kind of a lot, I can work up some patches to clarify what it all
> would look like.
>

Yeah sounds interesting.

Thanks
--David Kaplan

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Josh Poimboeuf]

On Fri, Oct 10, 2025 at 09:13:56PM +0000, Kaplan, David wrote:
> > It makes it clearer *why* retpolines are enabled: to mitigate Spectre v2
> > for older hardware.  (Though, frustratingly, retpolines have made a
> > comeback thanks to ITS.)
> 
> I don't think you mean 'enabled' here, you mean why they're being
> built into the kernel?  If retpolines are being enabled at runtime,
> that is reported via sysfs.

Right, I meant compiled in.

> > If I know I won't be running my kernel on old HW, this would make it
> > easy to phase out old mitigations that are no longer needed, that
> > otherwise uglify the code and might affect performance even when they're
> > disabled at runtime.
> 
> To check if I'm understanding right, is the idea that if you have an
> ALTERNATIVE that is based on some feature flag (like
> X86_FEATURE_CLEAR_CPU_BUF) but your kernel is built without any
> support for those mitigations that need that then that macro would
> essentially get deleted at compile time so you don't have the extra
> NOPs?  That seems useful.

If we decide we care enough about removing those NOPs, then yes, that
would be a use case.  We could wrap the CLEAR_CPU_BUFFERS definition
with #ifdef CONFIG_UGLY_CLEAR_CPU_BUFFERS or whatever.

> And if you don't need any retpoline support then you remove retpolines
> from your compile options?

Right.

-- 
Josh

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[David Laight]

On Fri, 10 Oct 2025 01:14:37 +0200
Borislav Petkov <bp@alien8.de> wrote:

> On Thu, Oct 09, 2025 at 06:13:20PM +0000, Kaplan, David wrote:
> > If we really want to optimize a CONFIG_CPU_MITIGATIONS=n kernel, why not
> > also look at alternatives that will never be enabled?
> > 
> > All the extra NOPs I think can affect performance in various ways and if
> > there was a way at compile time to know that the alternative would never be
> > enabled (because the feature is completely dependent on a cpu mitigation)
> > you could eliminate the NOPs...  
> 
> I don't see why not. That mitigations gunk should be just like any other
> CONFIG_-controllable item and not simply "leak" into the build because, oh
> well, we've done it this way from the very beginning and no one should touch
> it.
> 
> So yeah, eventually we should try this. I've been experimenting with
> untangling bugs.c today, will check how much it actually saves us when
> I finish beating the stinking pile into submission.
> 

There are systems (probably with a busybox/buildroot userspace) where,
even if everything doesn't run as root, any access that manages to add
any code will likely give you root access.
So all the mitigations are just pointless.
Similarly if you disable 'page table separation' (which 'trivially'
allows programs to read kernel memory) there is no point compiling
in anything else at all.

I'd even suspect that Linus disables them all on his kernel build system.

In both cases you may also want to compile out clac/stac because of
their performance impact on most cpu.

	David

[tip: x86/urgent] x86/bugs: Qualify RETBLEED_INTEL_MSG

[tip-bot2 for David Kaplan]

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID:     204ced4108f5d38f6804968fd9543cc69c3f8da6
Gitweb:        https://git.kernel.org/tip/204ced4108f5d38f6804968fd9543cc69c3f8da6
Author:        David Kaplan <david.kaplan@amd.com>
AuthorDate:    Fri, 03 Oct 2025 12:19:36 -05:00
Committer:     Borislav Petkov (AMD) <bp@alien8.de>
CommitterDate: Tue, 21 Oct 2025 12:32:28 +02:00

x86/bugs: Qualify RETBLEED_INTEL_MSG

When retbleed mitigation is disabled, the kernel already prints an info
message that the system is vulnerable.  Recent code restructuring also
inadvertently led to RETBLEED_INTEL_MSG being printed as an error, which is
unnecessary as retbleed mitigation was already explicitly disabled (by config
option, cmdline, etc.).

Qualify this print statement so the warning is not printed unless an actual
retbleed mitigation was selected and is being disabled due to incompatibility
with spectre_v2.

Fixes: e3b78a7ad5ea ("x86/bugs: Restructure retbleed mitigation")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220624
Signed-off-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251003171936.155391-1-david.kaplan@amd.com
---
 arch/x86/kernel/cpu/bugs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 6a526ae..e08de5b 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1463,7 +1463,9 @@ static void __init retbleed_update_mitigation(void)
 			break;
 		default:
 			if (retbleed_mitigation != RETBLEED_MITIGATION_STUFF) {
-				pr_err(RETBLEED_INTEL_MSG);
+				if (retbleed_mitigation != RETBLEED_MITIGATION_NONE)
+					pr_err(RETBLEED_INTEL_MSG);
+
 				retbleed_mitigation = RETBLEED_MITIGATION_NONE;
 			}
 		}

Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

[Borislav Petkov]

On Fri, Oct 10, 2025 at 01:14:37AM +0200, Borislav Petkov wrote:
> On Thu, Oct 09, 2025 at 06:13:20PM +0000, Kaplan, David wrote:
> > If we really want to optimize a CONFIG_CPU_MITIGATIONS=n kernel, why not
> > also look at alternatives that will never be enabled?
> > 
> > All the extra NOPs I think can affect performance in various ways and if
> > there was a way at compile time to know that the alternative would never be
> > enabled (because the feature is completely dependent on a cpu mitigation)
> > you could eliminate the NOPs...
> 
> I don't see why not. That mitigations gunk should be just like any other
> CONFIG_-controllable item and not simply "leak" into the build because, oh
> well, we've done it this way from the very beginning and no one should touch
> it.
> 
> So yeah, eventually we should try this. I've been experimenting with
> untangling bugs.c today, will check how much it actually saves us when
> I finish beating the stinking pile into submission.

So I can't say that it is insignificant:

   text    data     bss     dec     hex filename
30787172        11613226        7863812 50264210        2fef892 vmlinux.with
30210273        11598338        6061260 47869871        2da6faf vmlinux.without

that's ~500K code on my tailored config, meaning I haven't even enabled all
mitigations. So I'm thinking we should do this, but slowly, piecemeal, until
we have settled on the layout.

I'll send some patches soon to gather opinions...

Thx.

-- 
Regards/Gruss,
    Boris.

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