linux-kernel - Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL

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

Message-ID: <20251006131126.GBaOO__iUbQHNR6QhW@fat_crate.local>
Date: Mon, 6 Oct 2025 15:11:26 +0200
From: Borislav Petkov <bp@...en8.de>
To: David Kaplan <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,
	"H . Peter Anvin" <hpa@...or.com>,
	Klaus Kusche <klaus.kusche@...puterix.info>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG

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