linux-kernel - RE: [PATCH v4 49/63] objtool/klp: Add --checksum option to generate per-function checksums

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:
 <SN6PR02MB4157F236604B6780327E6B43D4CCA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Wed, 12 Nov 2025 02:26:18 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Michael Kelley <mhklinux@...look.com>, Josh Poimboeuf
	<jpoimboe@...nel.org>
CC: "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Petr Mladek <pmladek@...e.com>, Miroslav
 Benes <mbenes@...e.cz>, Joe Lawrence <joe.lawrence@...hat.com>,
	"live-patching@...r.kernel.org" <live-patching@...r.kernel.org>, Song Liu
	<song@...nel.org>, laokz <laokz@...mail.com>, Jiri Kosina <jikos@...nel.org>,
	Marcos Paulo de Souza <mpdesouza@...e.com>, Weinan Liu <wnliu@...gle.com>,
	Fazla Mehrab <a.mehrab@...edance.com>, Chen Zhongjin
	<chenzhongjin@...wei.com>, Puranjay Mohan <puranjay@...nel.org>, Dylan Hatch
	<dylanbhatch@...gle.com>, Peter Zijlstra <peterz@...radead.org>
Subject: RE: [PATCH v4 49/63] objtool/klp: Add --checksum option to generate
 per-function checksums

From: Michael Kelley <mhklinux@...look.com> Sent: Tuesday, November 11, 2025 5:39 PM
> 
> From: Josh Poimboeuf <jpoimboe@...nel.org> Sent: Tuesday, November 11, 2025 12:09 PM
> >
> > On Wed, Nov 05, 2025 at 03:22:58PM +0000, Michael Kelley wrote:
> > > > Thanks for reporting that.  I suppose something like the below would work?
> > > >
> > > > Though, maybe the missing xxhash shouldn't fail the build at all.  It's
> > > > really only needed for people who are actually trying to run klp-build.
> > > > I may look at improving that.
> > >
> > > Yes, that would probably be better.
> > >
> > > >
> > > > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > > > index 48928c9bebef1..8b95166b31602 100644
> > > > --- a/tools/objtool/Makefile
> > > > +++ b/tools/objtool/Makefile
> > > > @@ -12,7 +12,7 @@ ifeq ($(SRCARCH),loongarch)
> > > >  endif
> > > >
> > > >  ifeq ($(ARCH_HAS_KLP),y)
> > > > -	HAVE_XXHASH = $(shell echo "int main() {}" | \
> > > > +	HAVE_XXHASH = $(shell echo -e "#include <xxhash.h>\nXXH3_state_t *state;int main() {}" | \
> > > >  		      $(HOSTCC) -xc - -o /dev/null -lxxhash 2> /dev/null && echo y || echo > n)
> > > >  	ifeq ($(HAVE_XXHASH),y)
> > > >  		BUILD_KLP	 := y
> > >
> > > Indeed this is what I had in mind for the enhanced check. But the above
> > > gets a syntax error:
> > >
> > > Makefile:15: *** unterminated call to function 'shell': missing ')'.  Stop.
> > > make[4]: *** [Makefile:73: objtool] Error 2
> > >
> > > As a debugging experiment, adding only the -e option to the existing code
> > > like this shouldn't affect anything,
> > >
> > > 	HAVE_XXHASH = $(shell echo -e "int main() {}" | \
> > >
> > > but it causes HAVE_XXHASH to always be 'n' even if the xxhash library
> > > is present. So the -e option is somehow fouling things up.
> > >
> > > Running the equivalent interactively at a 'bash' prompt works as expected.
> > > And your proposed patch works correctly in an interactive bash. So
> > > something weird is happening in the context of make's shell function,
> > > and I haven't been able to figure out what it is.
> > >
> > > Do you get the same failures? Or is this some kind of problem with
> > > my environment?  I've got GNU make version 4.2.1.
> >
> > That's weird, it builds fine for me.  I have GNU make 4.4.1.
> 
> I've been able to debug this.  Two problems:
> 
> 1) On Ubuntu (both 20.04 and 24.04), /bin/sh and /usr/bin/sh are symlinks
> to "dash" (not "bash"). So the "shell" command in "make" invokes dash. The
> man page for dash shows that the built-in echo command accepts only -n as
> an option. The -e behavior of processing "\n" and similar sequences is always
> enabled. So on my Ubuntu systems, the "-e" is ignored by echo and becomes
> part of the C source code sent to gcc, and of course it barfs. Dropping the -e
> makes it work for me (and the \n is handled correctly), but that might not work
> with other shells. Using "/bin/echo" with the -e solves the problem in a more
> compatible way across different shells.
> 
> 2) With make v4.2.1 on my Ubuntu 20.04 system, the "#" character in the
> "#include" added to the echo command is problematic. "make" seems to be
> treating it as a comment character, though I'm not 100% sure of that
> interpretation. Regardless, the "#" causes a syntax error in the "make" shell
> command. Adding a backslash before the "#" solves that problem. On an Ubuntu
> 24.04 system with make v4.3, the "#" does not cause any problems. (I tried to put
> make 4.3 on my Ubuntu 20.04 system, but ran into library compatibility problems
> so I wasn’t able to definitively confirm that it is the make version that changes the
> handling of the "#"). Unfortunately, adding the backslash before the # does *not*
> work with make v4.3. The backslash becomes part of the C source code sent to
> gcc, which barfs. I don't immediately have a suggestion on how to resolve this
> in a way that is compatible across make versions.

Using "\043" instead of the "#" is a compatible solution that works in make
v4.2.1 and v4.3 and presumably all other versions as well.

Michael