linux-kernel - Re: [klibc] [PATCH net-next] net: uapi: Provide an UAPI definition of 'struct sockaddr'

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: <0fc5b4ef-c468-416f-a065-f64989d75378@zytor.com>
Date: Tue, 20 Jan 2026 10:50:18 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Arnd Bergmann <arnd@...db.de>,
        Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
        Eric Dumazet <edumazet@...gle.com>,
        Kuniyuki Iwashima <kuniyu@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
        Willem de Bruijn <willemb@...gle.com>, libc-alpha@...rceware.org,
        "Carlos O'Donell" <carlos@...hat.com>,
        Adhemerval Zanella <adhemerval.zanella@...aro.org>,
        Rich Felker <dalias@...c.org>
Cc: Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
        linux-api@...r.kernel.org, klibc@...or.com
Subject: Re: [klibc] [PATCH net-next] net: uapi: Provide an UAPI definition of
 'struct sockaddr'

On 2026-01-05 05:50, Arnd Bergmann wrote:
> 
> This looks like the right approach to me. I have previously
> tried to introduce a 'struct __kernel_sockaddr' structure and
> use that in uapi headers in place of the libc sockaddr, but
> that seemed worse in the end, and introduce the same problems
> as using the existing __kernel_sockaddr_storage.
> 

You say "the same problems". It's not clear to me what that means.

Based on my own libc experience, hacking both a minimal (klibc) and a
maximal (glibc) libc, there are a *lot* of advantages to having
__kernel_* definitions available, *regardless* of if they are exported
into the libc namespace at all.

Specifically:

1. When calling explicit kernel interfaces, like ioctl(), it is the
   kernel interfaces, not the libc interfaces, that needs to be
   used. However, the rest of the application may need to include the
   libc headers.

2. The libc *implementation* may need to have both the kernel and the
   libc interfaces available.

In the case of struct sockaddr et al, it probably matters less,
because it isn't practical for them to be different for other
reasons, but it has been a real problem for things like termios.

On the flipside, for things where the kernel interfaces are inherently
necessary, we really want the libc authors to be able to use the uapi
headers. However, they have to be concerned about things like
namespace restrictions.

So I have a very, very strong vote for using and even expanding the
use of __kernel_* in the uapi headers. In fact, it would even be nice
to have a variant of "make headers_install" that automatically
transmogrifies symbols; if it isn't doable with simple pattern
matching then perhaps using coccinelle.

Allowing the libc authors to modify those transmogrification rules
would definitely be better than having various kinds of header guards.

	-hpa