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
next prev parent 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).