netdev - Re: [RFC PATCH net-next 0/5] net: In-kernel QUIC implementation with Userspace handshake

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: <2365b657-bea4-4527-9fce-ad11c690bde3@samba.org>
Date: Mon, 29 Apr 2024 17:20:22 +0200
From: Stefan Metzmacher <metze@...ba.org>
To: Xin Long <lucien.xin@...il.com>
Cc: network dev <netdev@...r.kernel.org>, davem@...emloft.net,
 kuba@...nel.org, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Steve French <smfrench@...il.com>,
 Namjae Jeon <linkinjeon@...nel.org>, Chuck Lever III
 <chuck.lever@...cle.com>, Jeff Layton <jlayton@...nel.org>,
 Sabrina Dubroca <sd@...asysnail.net>, Tyler Fanelli <tfanelli@...hat.com>,
 Pengtao He <hepengtao@...omi.com>,
 "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
 Samba Technical <samba-technical@...ts.samba.org>
Subject: Re: [RFC PATCH net-next 0/5] net: In-kernel QUIC implementation with
 Userspace handshake

Hi Xin Long,

>>
> Just confirmed from other ebpf experts, there are no in-kernel interfaces
> for loading and interacting with BPF maps/programs(other than from BPF itself).
> 
> It seems that we have to do this match in QUIC stack. In the latest QUIC
> code, I added quic_packet_get_alpn(), a 59-line function, to parse ALPNs
> and then it will search for the listen sock with these ALPNs in
> quic_sock_lookup().
> 
> I introduced 'alpn_match' module param, and it can be enabled when loading
> the module QUIC by:
> 
>    # modprobe quic alpn_match=1
> 
> You can test it by tests/sample_test in the latest code:
> 
>    Start 3 servers:
> 
>      # ./sample_test server 0.0.0.0 1234 \
>          ./keys/server-key.pem ./keys/server-cert.pem smbd
>      # ./sample_test server 0.0.0.0 1234 \
>          ./keys/server-key.pem ./keys/server-cert.pem h3
>      # ./sample_test server 0.0.0.0 1234 \
>          ./keys/server-key.pem ./keys/server-cert.pem ksmbd
> 
>    Try to connect on clients with:
> 
>      # ./sample_test client 127.0.0.1 1234 ksmbd
>      # ./sample_test client 127.0.0.1 1234 smbd
>      # ./sample_test client 127.0.0.1 1234 h3
> 
>    to see if the corresponding server responds.
> 
> There might be some concerns but it's also a useful feature that can not
> be implemented in userland QUICs. The commit is here:
> 
> https://github.com/lxin/quic/commit/de82f8135f4e9196b503b4ab5b359d88f2b2097f
> 
> Please check if this is enough for SMB applications.

It look great thanks!

> Note as a listen socket is now identified by [address + port + ALPN] when
> alpn_match=1, this feature does NOT require SO_REUSEPORT socket option to
> be set, unless one wants multiple sockets to listen to
> the same [address + port + ALPN].

I'd argue that this should be the default and be required before listen()
or maybe before bind(), so that it can return EADDRINUSE. As EADDRINUSE should only
happen for servers it might be useful to have a QUIC_SOCKOPT_LISTEN_ALPN instead of
QUIC_SOCKOPT_ALPN. As QUIC_SOCKOPT_ALPN on a client socket should not generate let
bind() care about the alpn value at all.

For listens on tcp you also need to specify an explicit port (at least in order
to be useful).

And it would mean that all application would use it and not block other applications
from using an explicit alpn.

Also an module parameter for this means the administrator would have to take care
of it, which means it might be unuseable if loaded with it.

I hope to find some time in the next weeks to play with this.
Should be relatively trivial create a prototype for samba's smbd.

Thanks!
metze