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

Message-ID: <20251210091645.GJ3707837@noisy.programming.kicks-ass.net>
Date: Wed, 10 Dec 2025 10:16:45 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...nel.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 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.

> 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 :-)

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*