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]
Date:   Sun, 24 Oct 2021 12:27:42 -0700
From:   Josh Poimboeuf <>
To:     Masahiro Yamada <>
Cc:     Rob Landley <>,
        "" <>,
        Andrii Nakryiko <>,
        Peter Zijlstra <>
Subject: Re: Commit 0d989ac2c90b broke my x86-64 build.

On Mon, Oct 25, 2021 at 03:13:40AM +0900, Masahiro Yamada wrote:
> On Sun, Oct 24, 2021 at 3:36 PM Rob Landley <> wrote:
> >
> > The attached config built fine before the above commit, doesn't build after. The
> > commit in question did nothing except remove support for building x86-64 without
> > libelf.
> You enable CONFIG_STACK_VALIDATION in your .config file.
> At least, you observed
> "warning: Cannot use CONFIG_STACK_VALIDATION=y, please install
> libelf-dev, libelf-devel or elfutils-libelf-devel"
> in the previous builds.

Unfortunately I think CONFIG_STACK_VALIDATION is no longer optional on
x86-64 these days, because of static calls and retpolines.  But it
should be possible to extricate them if that's a problem.

> > It took me a while to notice because the commit ONLY broke x86-64. I can still
> > build arm (32 and 64 bit), i686, m68k, mips/mipsel, powerpc, s390x, and sh4
> > without libelf in my cross compiler. Heck, I can still build i686. The change
> > seems to have added a unique build dependency to just x86-64.
> The other architectures are not affected because you cannot enable
> Please note only x86_64 selects HAVE_STACK_VALIDATION.
> > Rob
> >
> > P.S. Why do you need a special library to parse elf anyway? It's a fairly simple
> > file format, linux has include/linux.elf.h, the toolchain already has an objtool
> > prefixed for the appropriate cross compiler...

We didn't see the need to reinvent the wheel, and some of the ELF corner
cases are tricky.

Objtool heavily relies on libelf for both reading and writing.  The
kernel needs objtool to be robust.  Libelf has been solid.


Powered by blists - more mailing lists