linux-kernel - Re: [RFC PATCH 05/56] x86/bugs: Reset spectre

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: <4artgo3z5dysdfiplsfq2q5jbml4m44rmzghc6ghgva346tlsj@g77fwgoc5vd7>
Date: Wed, 5 Nov 2025 12:52:04 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>, 
	Peter Zijlstra <peterz@...radead.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>, 
	Alexander Graf <graf@...zon.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 05/56] x86/bugs: Reset spectre_v2 mitigations

On Wed, Nov 05, 2025 at 08:21:08PM +0000, Kaplan, David wrote:
> > > If "functions bad" then why not make cpu_select_mitigations() one big
> > > happy function with a ton of comments?  Just think of all the function
> > > savings ;-)
> >
> > If it makes it more readable, always. But I see your point.
> >
> 
> Josh's thinking was aligned with my original thinking.  And if the
> #ifdefs are the only problem, I think I can just make them
> __maybe_unused instead.
> 
> That said, using a single function also allows for some de-duplication
> of code.  There are several mitigations that all use the same feature
> flags or other things (like x86_return_thunk) and those only need to
> be reset once.  Having them all in a single function makes that easier
> to optimize if desired.  Here's the single function version if you
> want to check that out and see if this is better or not:

I'm thinking it's probably best to keep things separate and contained
rather than intermixing / deduplicating, otherwise we might have to
disentangle them again later on.

Someday in the distant future we might want to start phasing out some of
the mitigations due to abandoned HW.

Or we might end up deciding to have a more modular per-mitigation build.

A little bit of duplicate effort is no big deal.  Running in
stop_machine_nmi(), it's not exactly performance-sensitive code :-)

-- 
Josh