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: <20260130112309-28f2645b-e756-4173-96da-cf5c59191520@linutronix.de>
Date: Fri, 30 Jan 2026 11:34:15 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>, 
	Kuniyuki Iwashima <kuniyu@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Willem de Bruijn <willemb@...gle.com>, "David S. Miller" <davem@...emloft.net>, 
	Simon Horman <horms@...nel.org>, Shuah Khan <shuah@...nel.org>, 
	Matthieu Baerts <matttbe@...nel.org>, Mat Martineau <martineau@...nel.org>, 
	Geliang Tang <geliang@...nel.org>, Mickaël Salaün <mic@...ikod.net>, 
	Günther Noack <gnoack@...gle.com>, Alexei Starovoitov <ast@...nel.org>, 
	Daniel Borkmann <daniel@...earbox.net>, Jesper Dangaard Brouer <hawk@...nel.org>, 
	John Fastabend <john.fastabend@...il.com>, Stanislav Fomichev <sdf@...ichev.me>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>, 
	Yonghong Song <yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>, Hao Luo <haoluo@...gle.com>, 
	Jiri Olsa <jolsa@...nel.org>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-api@...r.kernel.org, Arnd Bergmann <arnd@...db.de>, linux-kselftest@...r.kernel.org, 
	mptcp@...ts.linux.dev, linux-security-module@...r.kernel.org, bpf@...r.kernel.org, 
	libc-alpha@...rceware.org, Carlos O'Donell <carlos@...hat.com>, 
	Adhemerval Zanella <adhemerval.zanella@...aro.org>, Rich Felker <dalias@...c.org>, klibc@...or.com, 
	Florian Weimer <fweimer@...hat.com>
Subject: Re: [PATCH net-next v2 0/4] net: uapi: Provide an UAPI definition of
 'struct sockaddr'

On Wed, Jan 21, 2026 at 07:27:29PM -0800, Jakub Kicinski wrote:
> On Tue, 20 Jan 2026 15:10:30 +0100 Thomas Weißschuh wrote:
> > Various UAPI headers reference 'struct sockaddr'. Currently the
> > definition of this struct is pulled in from the libc header
> > sys/socket.h. This is problematic as it introduces a dependency
> > on a full userspace toolchain.
> > 
> > Add a definition of 'struct sockaddr' to the UAPI headers.
> > Before that, reorder some problematic header inclusions in the selftests.
> 
> >  include/linux/socket.h                             | 10 ----------
> >  include/uapi/linux/if.h                            |  4 ----
> >  include/uapi/linux/libc-compat.h                   | 12 ++++++++++++
> >  include/uapi/linux/socket.h                        | 14 ++++++++++++++
> >  samples/bpf/xdp_adjust_tail_user.c                 |  6 ++++--
> >  samples/bpf/xdp_fwd_user.c                         |  7 ++++---
> >  samples/bpf/xdp_router_ipv4_user.c                 |  6 +++---
> >  samples/bpf/xdp_sample_user.c                      | 15 ++++++++-------
> >  samples/bpf/xdp_tx_iptunnel_user.c                 |  4 ++--
> >  tools/testing/selftests/landlock/audit.h           |  7 ++++---
> >  tools/testing/selftests/net/af_unix/diag_uid.c     |  9 +++++----
> >  tools/testing/selftests/net/busy_poller.c          |  3 ++-
> >  tools/testing/selftests/net/mptcp/mptcp_diag.c     | 11 ++++++-----
> >  tools/testing/selftests/net/nettest.c              |  4 ++--
> >  tools/testing/selftests/net/tcp_ao/icmps-discard.c |  6 +++---
> >  tools/testing/selftests/net/tcp_ao/lib/netlink.c   |  9 +++++----
> >  tools/testing/selftests/net/tun.c                  |  5 +++--
> >  17 files changed, 77 insertions(+), 55 deletions(-)
> 
> Are all those selftests / samples getting broken by this patch set?

Yes.

Some of them get broken by the new 'struct sockaddr', but some others are
already broken just by the new transitive inclusion of libc-compat.h.
So any header starting to use the compatibility machinery may trigger breakage
in code including UAPI headers before libc header, even for completely new type
definitions which themselves would not conflict with libc.

> I understand that we should avoid libc dependencies in uAPI but at
> least speaking for networking - building selftests without libc is..
> not a practical proposition?

I am not sure I understand. Some sort of libc will always be necessary.
And as the selftests are intended to exercise the low-level kernel APIs,
even those not supported by libc, the UAPI headers will also be necessary.

There is nolibc (tools/include/nolibc/) which is using the UAPI headers in
most cases, and aims to be compatible. And can be and already is used for
selftests, but it will be too limited for all of the networking selftests.
(Disclaimer: I am maintaining nolibc)

My goal is *not* to make the different headers less compatible on purpose.
But by removing the existing dependencies we can now enforce the checks in
CONFIG_UAPI_HEADER_TEST to prevent any new ones from creeping in. Therefore
preventing compatiblity issues in any new UAPI.


Thomas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ