linux-kernel - Re: [PATCH 0/2] kselftest: Support nolibc

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:   Thu, 6 Apr 2023 15:32:20 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     Shuah Khan <shuah@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] kselftest: Support nolibc

On Thu, Apr 06, 2023 at 04:20:29PM +0200, Willy Tarreau wrote:
> On Thu, Apr 06, 2023 at 02:56:28PM +0100, Mark Brown wrote:

> > At present the kselftest header can't be used with nolibc since it makes
> > use of vprintf() which is not available in nolibc and seems like it would
> > be inappropriate to implement given the minimal system requirements and
> > environment intended for nolibc.

> In fact we already have vfprintf(), and printf() is based on it, so
> wouldn't it just be a matter of adding vprintf() that calls vfprintf()
> for your case ? Maybe just something like this :

>   static int vprintf(const char *fmt, va_list args)
>   {
> 	return vfprintf(stdout, fmt, args);
>   }

> It's possible I'm missing something, but it's also possible you didn't
> find vfprintf() which is why I prefer to raise my hand ;-)

Oh, yes - I just didn't find that.  Can't remember what I searched for
but it didn't match.

> > This has resulted in some open coded
> > kselftests which use nolibc to test features that are supposed to be
> > controlled via libc and therefore better exercised in an environment with
> > no libc.

> Yeah that's ugly. In nolibc-test we now have two build targets so that
> we can more easily verify the compatibility between the default libc and
> nolibc, so my recommendation would be to stick to a common subset of both
> libcs, but not to rely on nolibc-specific stuff that could make tests
> harder to debug.

For these features we simply never want to run with a proper libc since
if we use a libc which has support for the features then we can't
meaningfully interact with them.  We're trying to test interfaces that
libc is supposed to use.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)