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: <e4167710-3667-497b-b12e-096fd06217d9@kernel.org>
Date: Mon, 18 Aug 2025 18:20:13 +0200
From: Matthieu Baerts <matttbe@...nel.org>
To: Stefan Metzmacher <metze@...ba.org>, Xin Long <lucien.xin@...il.com>,
 network dev <netdev@...r.kernel.org>
Cc: 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

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.

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 :)

(@Xin: BTW, thank you for working on this!)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.