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: <dccoaur5kkn4x6rbhtsqjwnswlokxyxtowkatbiwwb5b6etu3b@2pjtaijjjpmj>
Date: Tue, 9 Dec 2025 17:15:06 -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 Tue, Dec 09, 2025 at 10:24:19AM +0100, Peter Zijlstra wrote:
> On Mon, Dec 08, 2025 at 02:46:23PM -0800, Josh Poimboeuf wrote:
> > On Mon, Dec 08, 2025 at 10:51:09AM +0100, Peter Zijlstra wrote:
> > > On Sat, Dec 06, 2025 at 01:41:15PM -0800, Josh Poimboeuf wrote:
> > > >   # ./arch/x86/include/asm/smap.h:47: 	alternative("", "stac", X86_FEATURE_SMAP);
> > > >   # 47 "./arch/x86/include/asm/smap.h" 1
> > > > 	ALTERNATIVE "", "stac", "( 9*32+20)"
> > > > 
> > > 
> > > So the problem with the gas macro thing is that it doesn't allow for
> > > that nesting. I don't think we currently use it other than to define the
> > > ALTERNATIVE_2 and ALTERNATIVE_3 macros, but IIRC the reason I started
> > > all that was because it was fairly trivial to use things like
> > > CALL_NOSPEC in an alternative (where CALL_NOSPEC is already an
> > > alternative).
> > 
> > Trying to wrap my head around this nested alternative thing as I don't
> > see any current code doing that.  Does that only work when the inner
> > alternative points to the same first original instruction as the outer
> > one?  Or, can you patch anywhere inside the original or replacement?
> 
> They'd have to be at the exact same location.

Ok, so while the syntax itself is nested, the underlying behavior is
just stacking alternatives together, like ALTERNATIVE_2 and _3 already
do, correct?

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...

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.

-- 
Josh