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

Message-ID: <20250304195625.qcxvtv63fqqk6fx4@jpoimboe>
Date: Tue, 4 Mar 2025 11:56:25 -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 08:57:13AM -1000, Linus Torvalds wrote:
> On Tue, 4 Mar 2025 at 08:48, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Random ugly code, untested, special versions for different config options.
> >
> > __builtin_frame_address() is much more complex than just the old "use
> > a register variable".
> 
> On the gcc bugzilla that hpa opened, I also note that Pinski said that
> the __builtin_frame_address() is likely to just work by accident.
> 
> Exactly like the %rsp case.

Right, so they're equally horrible in that sense.

> I'd be much more inclined to look for whether marking the asm
> 'volatile' would be a more reliable model. Or adding a memory clobber
> or similar.

Believe me, I've tried those and they don't work.

> Those kinds of solutions would also hopefully not need different
> sequences for different config options. Because
> __builtin_frame_address() really *is* fundamentally fragile, and the
> fact that frame pointers change behavior is a pretty big symptom of
> that fragility.

While that may be theoretically true, the reality is that it produces
better code for Clang.

If the main argument is that it needs more testing, then sure, let's go
test more compiler versions.

-- 
Josh