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: <mnokj2q3ytnar4x2zhcazfaqrnxz353dsdczjgr7hxirlsf6pm@bn4ed3eou44p>
Date: Wed, 8 Oct 2025 18:07:02 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, 
	"Kaplan, David" <David.Kaplan@....com>, 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 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