netdev - Re: [PATCH net-next v4 02/15] net: build socket infrastructure for QUIC protocol

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: <b9300291-e828-47fa-b4d1-66934636bd7b@samba.org>
Date: Thu, 30 Oct 2025 12:29:19 +0100
From: Stefan Metzmacher <metze@...ba.org>
To: Xin Long <lucien.xin@...il.com>
Cc: network dev <netdev@...r.kernel.org>, quic@...ts.linux.dev,
 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>, Thomas Dreibholz <dreibh@...ula.no>,
 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>,
 Matthieu Baerts <matttbe@...nel.org>, John Ericson <mail@...nericson.me>,
 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 v4 02/15] net: build socket infrastructure for
 QUIC protocol

Am 29.10.25 um 20:57 schrieb Xin Long:
> On Wed, Oct 29, 2025 at 12:22 PM Stefan Metzmacher <metze@...ba.org> wrote:
>>
>> Hi Xin,
>>
>>> This patch lays the groundwork for QUIC socket support in the kernel.
>>> It defines the core structures and protocol hooks needed to create
>>> QUIC sockets, without implementing any protocol behavior at this stage.
>>>
>>> Basic integration is included to allow building the module via
>>> CONFIG_IP_QUIC=m.
>>>
>>> This provides the scaffolding necessary for adding actual QUIC socket
>>> behavior in follow-up patches.
>>>
>>> Signed-off-by: Pengtao He <hepengtao@...omi.com>
>>> Signed-off-by: Xin Long <lucien.xin@...il.com>
>>
>> ...
>>
>>> +module_init(quic_init);
>>> +module_exit(quic_exit);
>>> +
>>> +MODULE_ALIAS("net-pf-" __stringify(PF_INET) "-proto-261");
>>> +MODULE_ALIAS("net-pf-" __stringify(PF_INET6) "-proto-261");
>>
>> Shouldn't this use MODULE_ALIAS_NET_PF_PROTO(PF_INET, IPPROTO_QUIC)
>> instead?
>>
> Hi, Stefan,
> 
> If we switch to using MODULE_ALIAS_NET_PF_PROTO(), we still need to
> keep using the numeric value 261:
> 
>    MODULE_ALIAS_NET_PF_PROTO(PF_INET, 261);
>    MODULE_ALIAS_NET_PF_PROTO(PF_INET6, 261);
> 
> IPPROTO_QUIC is defined as an enum, not a macro. Since
> MODULE_ALIAS_NET_PF_PROTO() relies on __stringify(proto), it can’t
> stringify enum values correctly, and it would generate:
> 
>    alias:          net-pf-10-proto-IPPROTO_QUIC
>    alias:          net-pf-2-proto-IPPROTO_QUIC

Yes, now I remember...

Maybe we can use something like this:

-  IPPROTO_QUIC = 261,          /* A UDP-Based Multiplexed and Secure Transport */
+#define __IPPROTO_QUIC 261     /* A UDP-Based Multiplexed and Secure Transport */
+  IPPROTO_QUIC = __IPPROTO_QUIC,

and then

MODULE_ALIAS_NET_PF_PROTO(PF_INET, __IPPROTO_QUIC)

In order to make things clearer.

What do you think?

metze