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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjgGD1p2bOCOeTjikNKmyDJ9zH8Fxiv5A+ts3JYacD3fA@mail.gmail.com>
Date: Tue, 4 Mar 2025 08:48:29 -1000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...nel.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, 4 Mar 2025 at 08:21, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> I'm utterly confused, what are these new problems you're referring to?

Random ugly code, untested, special versions for different config options.

> And how specifically is this more fragile?

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

> AFAICT, there was one known bug before the patches.  Now there are zero
> known bugs.

Big surprise - since it hasn't been tested on very many compiler versions.

> I'm excited to hear we can get rid of a lot of old GCC cruft, but this
> has nothing to do with the compiler version.
>
> It's needed for CONFIG_UNWINDER_FRAME_POINTER, for all compiler
> versions.  Otherwise the callee may skip the frame pointer setup before
> doing the call.

So you claim. But the original ASM_CALL_CONSTRAINT code was for a gcc
bug that was reportedly fixed in gcc-7.1

So is it *actually* required?

Because in my testing, gcc doesn't move inline asms to before the
frame pointer setup any more.

But I actually didn't base my arguments on my very limited testing,
but on our own documented history of this thing.

In your own words from 8 years go in commit f5caf621ee35 ("x86/asm:
Fix inline asm call constraints for Clang"), just having the register
variable makes the problem go away:

    With GCC 7.2, however, GCC's behavior has changed.  It now changes its
    behavior based on the conversion of the register variable to a global.
    That somehow convinces it to *always* set up the frame pointer before
    inserting *any* inline asm.  (Therefore, listing the variable as an
    output constraint is a no-op and is no longer necessary.)

and the whole ASM_CALL_CONSTRAINT thing is just unnecessary.

So I repeat: why are we making the code worse?

               Linus