linux-kernel - Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers

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: <20250304224511.cnnxyof2eeuvolcv@jpoimboe>
Date: Tue, 4 Mar 2025 14:45:11 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	linux-tip-commits@...r.kernel.org,
	"Peter Zijlstra (Intel)" <peterz@...radead.org>,
	Brian Gerst <brgerst@...il.com>, "H. Peter Anvin" <hpa@...or.com>,
	x86@...nel.org
Subject: Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on
 frame pointers

On Tue, Mar 04, 2025 at 10:41:08AM -1000, Linus Torvalds wrote:
> On Tue, 4 Mar 2025 at 10:13, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Does clang even need it?
> 
> Bah. Yes it does. I may not have clang sources to try to look at, but
> I can do a test-build.
> 
> Anyway, I do think it would be better to make this compiler-specific,
> and keep gcc using the old tested case that works well regardless of
> whether frame pointers are enabled or not, since it doesn't _care_.

Problem is, the old ASM_CALL_CONSTRAINT is an output constraint, but the
new one with __builtin_frame_address() is an *input* constraint.  How
would you combine those into a single macro?

> And I think there's a better way to deal with the whole "generate
> better code when not needed" too, if clang really has to have that
> disgusting __builtin_frame_pointer() thing that then has problems when
> frame pointers aren't enabled.

But as I've mentioned, even the old ASM_CALL_CONSTRAINT macro affects
code generation for the non-FP case.  For both compilers.  Not sure why.

We don't want to punish the default ORC config -- (hopefully) used in
the vast majority of configs at this point -- for frame pointer sins.

> IOW, you could do something pointless like
> 
>    extern int unused_variable;
>   #define ASM_CALL_CONSTRAINT "+m" (unused_variable)
> 
> which generates a dependency that doesn't matter, and then doesn't
> then require preprocessor hacks for when it is empty.

... assuming that DTRT and doesn't trigger any side effects, for all
compiler versions, now and forever?

BTW, I'm not opposed to just forgetting all this mess and stripping out
frame pointers altogether.  They have no benefit compared to ORC.  And
objtool is pretty much mandatory at this point.

Then we'd no longer have to worry about which awful hack does the least
amount of harm for each compiler and all its supported versions.

And for the eventual red zone enablement, we can enter the light of
supported behavior with that "redzone" clobber, and use objtool to
make sure that gets used.

-- 
Josh