netdev - Re: [PATCH net-next v2 01/15] net: define IPPROTO_QUIC and SOL

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: <CADvbK_dztN+x1-M6L841X-JROxrQYh=ENQJC_E1TbcPXErkHSQ@mail.gmail.com>
Date: Mon, 18 Aug 2025 14:37:03 -0400
From: Xin Long <lucien.xin@...il.com>
To: Matthieu Baerts <matttbe@...nel.org>
Cc: Stefan Metzmacher <metze@...ba.org>, network dev <netdev@...r.kernel.org>, davem@...emloft.net, 
	kuba@...nel.org, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, 
	Simon Horman <horms@...nel.org>, Moritz Buhl <mbuhl@...nbsd.org>, 
	Tyler Fanelli <tfanelli@...hat.com>, Pengtao He <hepengtao@...omi.com>, linux-cifs@...r.kernel.org, 
	Steve French <smfrench@...il.com>, Namjae Jeon <linkinjeon@...nel.org>, 
	Paulo Alcantara <pc@...guebit.com>, Tom Talpey <tom@...pey.com>, kernel-tls-handshake@...ts.linux.dev, 
	Chuck Lever <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>, 
	Benjamin Coddington <bcodding@...hat.com>, Steve Dickson <steved@...hat.com>, Hannes Reinecke <hare@...e.de>, 
	Alexander Aring <aahringo@...hat.com>, David Howells <dhowells@...hat.com>, 
	Cong Wang <xiyou.wangcong@...il.com>, "D . Wythe" <alibuda@...ux.alibaba.com>, 
	Jason Baron <jbaron@...mai.com>, illiliti <illiliti@...tonmail.com>, 
	Sabrina Dubroca <sd@...asysnail.net>, Marcelo Ricardo Leitner <marcelo.leitner@...il.com>, 
	Daniel Stenberg <daniel@...x.se>, Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH net-next v2 01/15] net: define IPPROTO_QUIC and SOL_QUIC constants

On Mon, Aug 18, 2025 at 12:20 PM Matthieu Baerts <matttbe@...nel.org> wrote:
>
> Hi Stefan, Xin,
>
> On 18/08/2025 16:31, Stefan Metzmacher wrote:
> > Hi,
> >
> >> diff --git a/include/linux/socket.h b/include/linux/socket.h
> >> index 3b262487ec06..a7c05b064583 100644
> >> --- a/include/linux/socket.h
> >> +++ b/include/linux/socket.h
> >> @@ -386,6 +386,7 @@ struct ucred {
> >>   #define SOL_MCTP    285
> >>   #define SOL_SMC        286
> >>   #define SOL_VSOCK    287
> >> +#define SOL_QUIC    288
> >>     /* IPX options */
> >>   #define IPX_TYPE    1
> >> diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
> >> index ced0fc3c3aa5..34becd90d3a6 100644
> >> --- a/include/uapi/linux/in.h
> >> +++ b/include/uapi/linux/in.h
> >> @@ -85,6 +85,8 @@ enum {
> >>   #define IPPROTO_RAW        IPPROTO_RAW
> >>     IPPROTO_SMC = 256,        /* Shared Memory Communications        */
> >>   #define IPPROTO_SMC        IPPROTO_SMC
> >> +  IPPROTO_QUIC = 261,        /* A UDP-Based Multiplexed and Secure
> >> Transport    */
> >> +#define IPPROTO_QUIC        IPPROTO_QUIC
> >>     IPPROTO_MPTCP = 262,        /* Multipath TCP connection        */
> >>   #define IPPROTO_MPTCP        IPPROTO_MPTCP
> >>     IPPROTO_MAX
> >
> > Can these constants be accepted, soon?
> >
> > Samba 4.23.0 to be released early September will ship userspace code to
> > use them. It would be good to have them correct when kernel's start to
> > support this...
> >
> > It would also mean less risk for conflicting projects with the need for
> > such numbers.
> >
> > I think it's useful to use a value lower than IPPROTO_MAX, because it means
> > the kernel module can also be build against older kernels as out of tree
> > module
> > and still it would be transparent for userspace consumers like samba.
> > There are hardcoded checks for IPPROTO_MAX in inet_create, inet6_create,
> > inet_diag_register
> > and the value of IPPROTO_MAX is 263 starting with commit
> > d25a92ccae6bed02327b63d138e12e7806830f78 in 6.11.
>
> I would also recommend not changing IPPROTO_MAX here. When IPPROTO_MAX
> got increased to 263, this caused some (small) small issues because it
> was hardcoded in some userspace code if I remember well.
>
> It is unclear why IPPROTO_QUIC is using 261 and not 257, but it should
> not make any differences I suppose.
>
I agree, it should not.

I wasn’t sure if any other project was using 257, so to minimize the risk
of conflicts, I’ve been using this large value from the beginning.

> Note that for MPTCP, we picked 262, just in case the protocol number was
> limited to 8 bits, to fallback to IPPROTO_TCP: 262 & 0xFF = 6. At that
> time, we thought it was important, because we were the first ones to use
> a value higher than U8_MAX. At the end, it is good for new protocols,
> not to increase IPPROTO_MAX each time :)
>
Yes, this approach saves a lot of trouble for new protocols!

Thanks.