linux-kernel - Re: rcutorture initrd/nolibc build on ARMv8?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210120143743.GB77728@C02TD0UTHF1T.local>
Date:   Wed, 20 Jan 2021 14:37:43 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Willy Tarreau <w@....eu>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        linux-kernel@...r.kernel.org, valentin.schneider@....com
Subject: Re: rcutorture initrd/nolibc build on ARMv8?

On Wed, Jan 20, 2021 at 03:25:00PM +0100, Willy Tarreau wrote:
> On Wed, Jan 20, 2021 at 01:45:11PM +0000, Mark Rutland wrote:
> > There's still some latent issue when using nolibc (compared to using
> > glibc) where the init process never seems to exit, but that looks to be
> > orthogonal to the syscall numbering issue -- I'm currently digging into
> > that.
> 
> OK! Usually for me it does as in my preinit (which uses nolibc), if I
> exit I instantly get a kernel panic. In addition if I launch it after
> boot, it immediately exits and shows no issue. But maybe you're observing
> an artefact related to something else (process session, opened FD or
> anything else maybe).

Luckily this was nothing to do with nolibc -- the build system wasn't
regenerating the initramfs to use the correctly-compiled init, and
things were blowing up because the kernel couldn't find an init process.
With that regenerated it worked as intended.

I'll reply separately for the rest of the nolibc bits shortly.

Thanks,
Mark.