linux-kernel - Re: [PATCH 0/2] selftests/nolibc: small simplification of test development phase

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]

Date:   Mon, 23 Jan 2023 20:12:50 +0100
From:   Willy Tarreau <w@....eu>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Ammar Faizi <ammarfaizi2@...weeb.org>,
        linux-kernel@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 0/2] selftests/nolibc: small simplification of test
 development phase

On Mon, Jan 23, 2023 at 09:40:03AM -0800, Paul E. McKenney wrote:
> Except that when I install Ubuntu 20.04's version, I get this:
> 
> ------------------------------------------------------------------------
> 
> $ sudo make run-user
>   MKDIR   sysroot/x86/include
> make[1]: Entering directory '/home/git/linux-rcu/tools/include/nolibc'
> make[2]: Entering directory '/home/git/linux-rcu'
> make[2]: Leaving directory '/home/git/linux-rcu'
> make[2]: Entering directory '/home/git/linux-rcu'
>   INSTALL /home/git/linux-rcu/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/home/git/linux-rcu'
> make[1]: Leaving directory '/home/git/linux-rcu/tools/include/nolibc'
>   CC      nolibc-test
> 32 gettimeofday_null = -1 EFAULT        [FAIL]
> See all results in /home/git/linux-rcu/tools/testing/selftests/nolibc/run.out
> 
> ------------------------------------------------------------------------
> 
> I have attached run.out.
> 
> In contrast, with my hand-built qemu-x86_64, all tests passed.
> 
> This might be just a version-related bug, but figured I should let you
> guys know.

Interesting. Maybe something differs in the way it passes expectedly
invalid pointers to some syscalls. Keep in mind that it's using your
local kernel also, that could make a difference. I'm not that much keen
on trying to investigate that one to be honest, given that this user
mode is really meant to ease the life of test developers like Ammar
and myself who just want to focus on the correctness of the test they're
adding and not that much on the validity of the test itself in this
context. I suggest we keep this one in mind without putting too much
effort on it for now.

Thanks!
Willy