| 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
| ||
|
Message-ID:
<LV3PR12MB9265B9AA81E01A539214764A94E3A@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Mon, 6 Oct 2025 13:58:55 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
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" <x86@...nel.org>, "H .
Peter Anvin" <hpa@...or.com>, Klaus Kusche <klaus.kusche@...puterix.info>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] x86/bugs: Qualify RETBLEED_INTEL_MSG
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Monday, October 6, 2025 8:11 AM
> To: Kaplan, David <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
>
> 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@....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
Powered by blists - more mailing lists