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

Message-ID: <ewuawnlm44vqdxjm6iqtw4m5wvbqzcdblxkpwmozwf4ydhzzko@7rdo5ncnzjdb>
Date: Fri, 10 Oct 2025 18:20:52 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, 
	Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, 
	Peter Zijlstra <peterz@...radead.org>, 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

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