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:
 <SN6PR02MB4157212C49D6A6E2AFE0CAA9D4CCA@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Wed, 12 Nov 2025 01:39:24 +0000
From: Michael Kelley <mhklinux@...look.com>
To: 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: 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.

What a mess.

Michael