linux-kernel - Re: [PATCH v2 03/11] tools/nolibc/stdio: remove perror if NOLIBC_IGNORE

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: <20250921171323.GC28238@1wt.eu>
Date: Sun, 21 Sep 2025 19:13:23 +0200
From: Willy Tarreau <w@....eu>
To: Benjamin Berg <benjamin@...solutions.net>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
        linux-um@...ts.infradead.org, linux-kselftest@...r.kernel.org,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 03/11] tools/nolibc/stdio: remove perror if
 NOLIBC_IGNORE_ERRNO is set

On Sun, Sep 21, 2025 at 07:05:24PM +0200, Benjamin Berg wrote:
> This also ties to the question of the other mail. I prefer "errno" not
> to be available if it is not actually safe to use. UML does use threads
> in some places (and may use it extensively in the future). The current
> "errno" implementation is not threadsafe and I see neither an obvious
> way nor a need to change that. By setting NOLIBC_IGNORE_ERRNO any
> unsafe code will not compile and can be changed to use the sys_*
> functions to avoid errno.

That's the point I disagree with because here we're not using errno
more than printf() or dirent(). Why fix dirent() to build without errno
and break perror() ? Why not also break printf() then ? All of this must
be consistent. We're unbreaking some arbitrary functions and breaking
other arbitrary ones, that's not logical.

I'm totally fine with saying that errno shouldn't be defined when building
without errno, but all functions must continue to be defined. perror() is
used to print an error message, it's a valid use case just as printf() and
should remain.

If we disable perror for this, then we must also disable usage of printf
for consistency (and I don't want this either).

Willy