linux-kernel - Re: [PATCH] x86/hweight: Fix and improve __arch

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: <Z89TBVoRDLy66EuQ@gmail.com>
Date: Mon, 10 Mar 2025 22:00:53 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Uros Bizjak <ubizjak@...il.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86/hweight: Fix and improve __arch_hweight{32,64}()
 assembly


* Borislav Petkov <bp@...en8.de> wrote:

> On Mon, Mar 10, 2025 at 09:35:42PM +0100, Uros Bizjak wrote:
> > On Mon, Mar 10, 2025 at 9:12 PM Borislav Petkov <bp@...en8.de> wrote:
> > >
> > > On Mon, Mar 10, 2025 at 09:08:04PM +0100, Uros Bizjak wrote:
> > > > a) Use ASM_CALL_CONSTRAINT to prevent inline asm that includes call
> > > > instruction from being scheduled before the frame pointer gets set
> > > > up by the containing function, causing objtool to print a "call
> > > > without frame pointer save/setup" warning.
> > >
> > > The other two are ok but this is new. How do you trigger this? I've never seen
> > > it in my randconfig builds...
> > 
> > It is not triggered now, but without this constraint, nothing prevents
> > the compiler from scheduling the insn in front of frame creation.
> 
> Can you please stop with this silliness?
> 
> When we start doing git archeology months, years from now, it should 
> be perfectly clear why a commit was done. This one is not. So either 
> the compiler is doing the bad scheduling or it isn't. Things can't 
> just work by chance.

So this particular code generation aspect seems to be working by random 
implementational chance right now: objtool is basically a second, 
independent layer of tooling with its own assumptions and expectations, 
which is why objtool warnings are not hard build failures.

But whether unexpected instruction scheduling is known to occur or not 
with current compilers should be included in the changelog and is 
relevant information.

Thanks,

	Ingo