linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Josh Poimboeuf <jpoimboe@redhat.com>,
	Masahiro Yamada <masahiroy@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: Commit 0d989ac2c90b broke my x86-64 build.
Date: Sun, 24 Oct 2021 21:51:45 -0500	[thread overview]
Message-ID: <66ed460c-ac48-2b5a-e8e4-07613cf69ab0@landley.net> (raw)
In-Reply-To: <20211024192742.uo62mbqb6hmhafjs@treble>

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

  reply	other threads:[~2021-10-25  2:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-24  6:36 Commit 0d989ac2c90b broke my x86-64 build Rob Landley
2021-10-24 18:13 ` Masahiro Yamada
2021-10-24 19:27   ` Josh Poimboeuf
2021-10-25  2:51     ` Rob Landley [this message]
2021-10-25  9:04       ` Peter Zijlstra
2021-10-25 14:46         ` Josh Poimboeuf
2021-10-25 14:56           ` Peter Zijlstra
2021-10-25 18:59             ` Josh Poimboeuf
2021-10-25 20:01               ` Peter Zijlstra
2021-10-26  3:33                 ` Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66ed460c-ac48-2b5a-e8e4-07613cf69ab0@landley.net \
    --to=rob@landley.net \
    --cc=andrii@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).