linux-kernel - Re: [PATCH 8/8] x86/alternative: Convert alternatives to assembler macros

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: <7vkn3muot3bypt77funzc2vi5cgosv3lz6yktxqtxwqbmjtchp@jeuv7ayf5lbp>
Date: Wed, 10 Dec 2025 21:20:36 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>, 
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 8/8] x86/alternative: Convert alternatives to assembler
 macros

On Wed, Dec 10, 2025 at 10:16:45AM +0100, Peter Zijlstra wrote:
> On Tue, Dec 09, 2025 at 05:15:06PM -0800, Josh Poimboeuf wrote:
> 
> > Ok, so while the syntax itself is nested, the underlying behavior is
> > just stacking alternatives together, like ALTERNATIVE_2 and _3 already
> > do, correct?
> 
> Yup.
> 
> > While it's clever that the current implementation allows that kind of
> > nested syntax, it seems dangerous.  I don't see anything preventing the
> > inner ALTERNATIVE from being placed in the middle of the outer
> > ALTERNATIVE's original instructions, or anywhere in the outer's
> > replacement code.
> > 
> > It would be really easy to introduce CALL_NOSPEC in the middle of a
> > group of instructions in an ALTERNATIVE without realizing that you're
> > likely introducing some subtle or not-so-subtle bug on x86-32, which
> > just happens to hide an ALTERNATIVE_2 inside the CALL_NOSPEC...
> 
> I think I made objtool complain in that case, but I'm not sure.

I do see some checks there.  I'm not quite convinced all the edge cases
are covered.

> > The gas macro doesn't give you the leeway to make that mistake, so you'd
> > have to restructure the code slightly to make it fit into a proper
> > ALTERNATIVE_3.  Which is less magical and more clear, so that seems like
> > a good thing.
> 
> Perhaps, I'm not really a fan of the ALTERNATIVE_n() macros much. I
> think writing the nested ALTERNATIVE() form is actually more readable.
> But perhaps I'm the crazy one -- wouldn't be the first time :-)

The nesting might be more readable, but it feels like syntax sugar in a
way that's a conceptual mismatch compared to how the alternatives are
actually applied.

> Anyway, seeing how its not actually used, and I've since solved the case
> that gave rise to all this completely differently, perhaps I should just
> shut up and let you do the conversion.
> 
> I mean, we will have to do ALTERNATIVE_4() at some point, and it will be
> glorious... *sigh*

Well, at least this makes it a unified implementation so the ugly is
only confined to a single place :-)

-- 
Josh