linux-kernel - Re: Commit 0d989ac2c90b broke my x86-64 build.

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]

Date:   Sun, 24 Oct 2021 21:51:45 -0500
From:   Rob Landley <rob@...dley.net>
To:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Masahiro Yamada <masahiroy@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
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 <rob@...dley.net> 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
dependency.

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

  http://lists.landley.net/pipermail/toybox-landley.net/2020-July/011898.html

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

FYI:

  git clone https://github.com/landley/toybox
  git clone https://github.com/richfelker/musl-cross-make
  git clone https://github.com/torvalds/linux
  cd musl-cross-make
  ../toybox/scripts/mcm-buildall.sh
  cd ../toybox
  ln -s ../musl-cross-make/ccc ccc
  LINUX="$PWD"/../linux CROSS=allnonstop scripts/mkroot.sh

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 mkroot.sh script that builds the systems is currently 254 lines of bash,
hopefully readable...

>> The other architectures are not affected because you cannot enable
>> CONFIG_STACK_VALIDATION.
>> 
>> 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?)

Rob