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: <20250304200935.wheet2xouue54bbv@jpoimboe>
Date: Tue, 4 Mar 2025 12:09:35 -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 11:56:27AM -0800, Josh Poimboeuf wrote:
> 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.

BTW.  I confirmed that even the current version of ASM_CALL_CONSTRAINT
affects code generation for non-frame-pointer builds.

No matter what the ASM_CALL_CONSTRAINT implementation looks like, we
really don't want it affecting code generation for the ORC case.

So making ASM_CALL_CONSTRAINT empty for CONFIG_UNWINDER_ORC is a good
thing for code generation, regardless of the ASM_CALL_CONSTRAINT
implementation.

-- 
Josh