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: <1602F93C-94B6-40DA-A2F6-B8D4C0E24C1F@zytor.com>
Date: Mon, 10 Mar 2025 07:49:56 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
CC: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
        tip-bot2 for Josh Poimboeuf <tip-bot2@...utronix.de>,
        linux-tip-commits@...r.kernel.org,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Brian Gerst <brgerst@...il.com>, x86@...nel.org
Subject: Re: [tip: x86/asm] x86/asm: Make ASM_CALL_CONSTRAINT conditional on frame pointers

On March 7, 2025 5:38:14 PM PST, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>On Fri, Mar 07, 2025 at 03:29:00PM -0800, H. Peter Anvin wrote:
>> On March 7, 2025 3:21:57 PM PST, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>> >On Sat, Mar 08, 2025 at 12:05:29AM +0100, Ingo Molnar wrote:
>> >> 
>> >> * H. Peter Anvin <hpa@...or.com> wrote:
>> >> 
>> >> > > #endif /* __ASSEMBLY__ */
>> >> > 
>> >> > So we are going to be using this version despite the gcc maintainers 
>> >> > telling us it is not supported?
>> >> 
>> >> No, neither patches are in the x86 tree at the moment.
>> >
>> >FWIW, the existing ASM_CALL_CONSTRAINT is also not supported, so this
>> >patch wouldn't have changed anything in that respect.
>> >
>> >Regardless I plan to post a new patch set soon with a bunch of cleanups.
>> >
>> >It will keep the existing ASM_CALL_CONSTRAINT in place for GCC, and will
>> >use the new __builtin_frame_address(0) input constraint for Clang only.
>> >
>> >There will be a new asm_call() interface to hide the mess.
>> >
>> 
>> Alternatively, you can co-opt the gcc BR I already filed on this and
>> argue there that there are new reasons to support the alternate
>> construct.
>
>We hopefully won't need those hacks much longer anyway, as I'll have
>another series to propose removing frame pointers for x86-64.
>
>x86-32 can keep frame pointers, but doesn't need the constraints.  It's
>not supported for livepatch so it doesn't need to be 100% reliable.
>Worst case, an unwind skips a frame, but the call address still shows up
>on stack trace dumps prepended with '?'.
>
>I plan to do the asm_call() series before the FP removal series because
>it's presumably less disruptive, and it has a bunch more orthogonal
>cleanups.
>

I should probably clarify that this wasn't flippant, but a serious request.

If this works by accident on existing gcc, and works on clang, that is a very good reason for making it the supported way of doing this going forward for both compilers. Per-compiler hacks are nasty, and although we are pretty good about coping with them in the kernel, some user space app developer is guaranteed to get it wrong. 

Frame pointers are actually more relevant in user space because user space tends to be compiled with a wider range of debug and architecture options, and of course there is simply way more user space code out there.