linux-kernel - Re: [PATCH 0/9] tools/nolibc: fix build issues on aarch64 after unistd cleanup

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] [day] [month] [year] [list]

Message-ID: <20210122154241.GH2743@paulmck-ThinkPad-P72>
Date:   Fri, 22 Jan 2021 07:42:41 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Mark Rutland <mark.rutland@....com>
Cc:     Willy Tarreau <w@....eu>, valentin.schneider@....com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] tools/nolibc: fix build issues on aarch64 after
 unistd cleanup

On Fri, Jan 22, 2021 at 12:25:42PM +0000, Mark Rutland wrote:
> On Fri, Jan 22, 2021 at 04:03:26AM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 21, 2021 at 11:11:17AM +0000, Mark Rutland wrote:
> > 
> > [ . . . ]
> > 
> > > I've given this a spin atop v5.11-rc4, building natively on arm64 on a
> > > Debian 10.7 system, and with the whole series applied I'm able to run
> > > the rcutorture kvm.sh script without issue (the CONFIG warnings are
> > > unrelated to nolibc):
> > > 
> > > | [mark@...vadlaks:~/src/linux]% ./tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 255 --configs "TREE03"  --kmake-arg "CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64" --duration 1
> > > | Creating a statically linked C-language initrd
> > > | Done creating a statically linked C-language initrd
> > > | Results directory: /home/mark/src/linux/tools/testing/selftests/rcutorture/res/2021.01.21-10.53.24
> > > | ./tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 255 --configs TREE03 --kmake-arg CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 --duration 1
> > > | ----Start batch 1: Thu 21 Jan 10:53:24 GMT 2021
> > > | TREE03 16: Starting build. Thu 21 Jan 10:53:24 GMT 2021
> > > | TREE03 16: Waiting for build to complete. Thu 21 Jan 10:53:24 GMT 2021
> > > | TREE03 16: Build complete. Thu 21 Jan 10:56:25 GMT 2021
> > > | ---- TREE03 16: Kernel present. Thu 21 Jan 10:56:25 GMT 2021
> > > | ---- Starting kernels. Thu 21 Jan 10:56:25 GMT 2021
> > > | ---- All kernel runs complete. Thu 21 Jan 10:57:35 GMT 2021
> > > | ---- TREE03 16: Build/run results:
> > > |  --- Thu 21 Jan 10:53:24 GMT 2021: Starting build
> > > | :CONFIG_HYPERVISOR_GUEST=y: improperly set
> > > | :CONFIG_KVM_GUEST=y: improperly set
> > 
> > These two (apparently harmless) error messages are due to these lines
> > in CFcommon:
> > 
> > CONFIG_HYPERVISOR_GUEST=y
> > CONFIG_KVM_GUEST=y
> 
> Yup; I had figured this out, but since this wasn't getting in the way of
> actually running the torture tests I had assumed we could deal with that
> at some indefinite point in the future, or simply ignore it. ;)
> 
> > It looks like CONFIG_HYPERVISOR_GUEST is specific to x86, while KVM_GUEST
> > is specific to x86, powerpc, and mips.  (It appears that arm64 doesn't
> > need anything here?) 
> 
> Yup, we don't need any special options -- arm64 doesn't stricly need any
> guest enlightenment to run under a hypervisor, so we never had a need
> for KVM_GUEST or HYPERVISOR_GUEST. We have all the common
> paravritualized drivers (e.g. virtio) in defconfig too, so that should
> all work out of the box.
> 
> > Given this variety, I need to make rcutorture know very early on what
> > arch it is building for.  My current approach of looking at the
> > vmlinux file won't work because I need to get the config right before
> > building the kernel.
> > 
> > One approach would be to look at the initrd/init file, but doing this
> > reliably would mean removing the ability for users to supply their own
> > initrd file trees.  Another approach would be to look at the current
> > environment, perhaps using "uname -m", which will work until someone
> > wants to cross-build.  Yet another approach would be to parse the target
> > line from the output of "${CROSS_COMPILE}gcc -v".
> > 
> > Left to myself, I would parse the output of "${CROSS_COMPILE}gcc -v".
> 
> Heh, I hadn't considered parsing the target line from that output, and I
> guess that works for native builds where "${CROSS_COMPILE}" = "". Neat
> trick!

Credit to Willy Tarreau.  Me, I just realized that he needed to do
-something- to create rcutorture's initrd.  ;-)

> That sounds sensible to me!

Let me see what I can do.

My thought is to add optional CFcommon.<arch> files, and pull them in
when there is a match.  But I will give it more thought.

							Thanx, Paul