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 21:51:45 -0500
From:   Rob Landley <>
To:     Josh Poimboeuf <>,
        Masahiro Yamada <>
Cc:     "" <>,
        Andrii Nakryiko <>,
        Peter Zijlstra <>
Subject: Re: Commit 0d989ac2c90b broke my x86-64 build.

On 10/24/21 2:27 PM, Josh Poimboeuf wrote:
> 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.

When I first noticed this dependency in 2018 it was because the ORC unwinder
selected it, which is why I selected UNWINDER_FRAME_POINTER to avoid that

>> 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.

I turned off CONFIG_STACK_VALIDATION=y because I didn't want the dependency. It
appears to have crept back in since.

> Unfortunately I think CONFIG_STACK_VALIDATION is no longer optional on
> x86-64 these days, because of static calls and retpolines.

Does it need stack validation, or just a frame unwinder?

> But it
> should be possible to extricate them if that's a problem.

Yes please. How would I go about that? (Is there something to grep for?)

This is to build a small kernel that runs dedicated code. It hasn't got selinux
or containers, and part of the goal is to have a minimal self-contained build
system which can be binary audited against Ken Thompson's "trusting trust" attack:

...and then bootstrap up to arbitrarily complexity using nothing but the audited
binaries built from known source with no external dependencies.

Last go-round I got the minimal system down to 7 packages (busybox, uclibc,
linux, make, bash, gcc, binutils), under natively rebuilt itself under itself,
and under which I built Linux From Scratch (and large chunks of BLFS).

I'm now working to get it down to 4 (toybox, musl, tinycc, linux) and this time
targeting an AOSP build under the result.

>> > 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.


  git clone
  git clone
  git clone
  cd musl-cross-make
  cd ../toybox
  ln -s ../musl-cross-make/ccc ccc
  LINUX="$PWD"/../linux CROSS=allnonstop scripts/

Assuming I haven't typoed anything and live repo tips don't have bug du jour,
that should build 21 cross toolchains (and 20 native: todo make armv7r work),
then attempt to build tiny bootable qemu systems for each target (I think 14
currently boot to a shell prompt, ala (cd root/sh4 && ./qemu-*.sh)

The script that builds the systems is currently 254 lines of bash,
hopefully readable...

>> The other architectures are not affected because you cannot enable
>> Please note only x86_64 selects HAVE_STACK_VALIDATION.

Indeed. I'd like to tweak the config so I can disable stack validation and thus
this dependency. It worked fine for me before the above commit, and a kernel
with the following quick hack just built and booted for me:

--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
-       select HAVE_STACK_VALIDATION            if X86_64
+       select HAVE_STACK_VALIDATION            if X86_64 && !UNWINDER_FRAME_POINTER

The question is the right way to go about it. (New config symbol?)


Powered by blists - more mailing lists