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: <CAHk-=wgtnKe+pH2Sx7C0u_UDzan6paTMesRDhAyDEAcCptyuuw@mail.gmail.com>
Date: Tue, 4 Mar 2025 10:25:26 -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 10:13, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Tue, 4 Mar 2025 at 09:56, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> >
> > While that may be theoretically true, the reality is that it produces
> > better code for Clang.
>
> Does clang even need it? Last we did any changes for clang, it wasn't
> because clang needed the marker at all, it was because clang was
> unhappy with the stack pointer register define being local.

Put another way: if we make this conditional, it would make a whole
lot more sense to make it conditional on the *compiler*, not on some
random kernel config option.

At least making some "use this to mark inline asms" be
compiler-specific makes sense. We already do exactly that for other
compiler issues (we used to have the "asm goto output" gcc bugs that
way, and we still do asm_inline that way)

And as far as I know, we've only ever needed this for gcc, and gcc has
never had any problem with just using %rsp as the input - whether as a
local variable or as a global one.

But regardless, changing from one very tested model to another, when a
gcc person already has said that the new model isn't reliable, and
doing it for gcc because of a *clang* issue, really seems all kinds of
insane.

                 Linus