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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20210119161901.GA14667@1wt.eu>
Date:   Tue, 19 Jan 2021 17:19:01 +0100
From:   Willy Tarreau <w@....eu>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     linux-kernel@...r.kernel.org, valentin.schneider@....com,
        mark.rutland@....com
Subject: Re: rcutorture initrd/nolibc build on ARMv8?

Hi Paul,

On Tue, Jan 19, 2021 at 07:31:47AM -0800, Paul E. McKenney wrote:
> Hello, Willy,
> 
> Some people are having trouble running rcutorture on ARMv8.  They
> get things like this from the nolibc build of initrd:
> 
> https://paste.debian.net/1181762/
> 
> The nolibc.h file says this:
> 
> /* Some archs (at least aarch64) don't expose the regular syscalls anymore by
>  * default, either because they have an "_at" replacement, or because there are
>  * more modern alternatives. For now we'd rather still use them.
>  */
> 
> Are these build failures expected behavior on ARMv8?

No, I don't think so. I'm regularly building my own init using this,
and it works on various platforms including aarch64, while it makes
use of a number of such syscalls.

>From what I'm seeing, this seems to happen each time in such a construct:

    #if defined(__NR_new_name)
         use __NR_new_name
    #else
         use __NR_old_name
    #endif

with the error appearing on old_name. So I guess that we're rather facing a
case where a number of such __NR_* entries are not defined because presumably
one include file might be missing (probably from a recent change of headers
dependency).

I can't spot from the report above the original C file that was attempted
to be built, it makes me think we tried to compile directly the .h file.

Having it run through sh -x would help me try to locate the root cause or
possibly even attempt to reproduce it.

Thanks,
Willy