netdev - Re: quic in-kernel implementation?

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: <59FC50B0-DC25-42A9-9981-F03646BA65A8@oracle.com>
Date:   Tue, 8 Jun 2021 21:26:51 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Stefan Metzmacher <metze@...ba.org>,
        Alexander Ahring Oder Aring <aahringo@...hat.com>
CC:     Steve French <smfrench@...il.com>,
        Aurélien Aptel <aaptel@...e.com>,
        Network Development <netdev@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>,
        Leif Sahlberg <lsahlber@...hat.com>,
        Steven Whitehouse <swhiteho@...hat.com>
Subject: Re: quic in-kernel implementation?



> On Jun 8, 2021, at 3:36 AM, Stefan Metzmacher <metze@...ba.org> wrote:
> 
> Am 08.06.21 um 05:04 schrieb Steve French:
>> On Mon, Jun 7, 2021 at 11:45 AM Aurélien Aptel <aaptel@...e.com> wrote:
>>> 
>>> Alexander Ahring Oder Aring <aahringo@...hat.com> writes:
>>>> as I notice there exists several quic user space implementations, is
>>>> there any interest or process of doing an in-kernel implementation? I
>>>> am asking because I would like to try out quic with an in-kernel
>>>> application protocol like DLM. Besides DLM I've heard that the SMB
>>>> community is also interested into such implementation.
>>> 
>>> Yes SMB can work over QUIC. It would be nice if there was an in-kernel
>>> implementation that cifs.ko could use. Many firewall block port 445
>>> (SMB) despite the newer version of the protocol now having encryption,
>>> signing, etc. Using QUIC (UDP port 443) would allow for more reliable
>>> connectivity to cloud storage like azure.
>>> 
>>> There are already multiple well-tested C QUIC implementation out there
>>> (Microsoft one for example, has a lot of extra code annotation to allow
>>> for deep static analysis) but I'm not sure how we would go about porting
>>> it to linux.
>>> 
>>> https://github.com/microsoft/msquic
>> 
>> Since the Windows implementation of SMB3.1.1 over QUIC appears stable
>> (for quite a while now) and well tested, and even wireshark can now decode it, a
>> possible sequence of steps has been discussed similar to the below:
>> 
>> 1) using a userspace port of QUIC (e.g. msquic since is one of the more tested
>> ports, and apparently similar to what already works well for QUIC on Windows
>> with SMB3.1.1) finish up the SMB3.1.1 kernel pieces needed for running over
>> QUIC
> 
> Instead of using userspace upcalls directly, it would be great if we could hide
> behind a fuse-like socket type, in order to keep the kernel changes in fs/cifs (and other parts)
> tiny and just replace the socket(AF_INET) call, but continue to use a
> stream socket (likely with a few QUIC specific getsockopt/setsockopt calls).
> 
> It would also allow userspace applications like Samba's smbclient and smbd
> to use it that way too.

That's interesting as a development scaffold.

However, IMO the interesting part of QUIC for us is transport
layer security. NFS already has TLS via RPC-over-TLS, and we
intend to have a full in-kernel implementation soon. Using a
user-space transport protocol implementation is likely to be
an unacceptable step backwards in terms of performance for us.
NFS connections are long-lived, no benefit at all from the
special 0-RTT mechanisms.

I hope the end goal is to have a full in-kernel implementation
of QUIC at some point, otherwise I don't see Linux QUIC ever
being on par with current TCP performance for a kernel
consumer.


>> 2) then switch focus to porting a smaller C userspace implementation of
>> QUIC to Linux (probably not msquic since it is larger and doesn't
>> follow kernel style)
>> to kernel in fs/cifs  (since currently SMB3.1.1 is the only protocol
>> that uses QUIC,
>> and the Windows server target is quite stable and can be used to test against)> 3) use the userspace upcall example from step 1 for
>> comparison/testing/debugging etc.
>> since we know the userspace version is stable
> 
> With having the fuse-like socket before it should be trivial to switch
> between the implementations.

Although switching QUIC implementations is a cool trick for
rapid prototyping, I'm unclear on the eventual user benefit
of it.


>> 4) Once SMB3.1.1 over QUIC is no longer experimental, remove, and
>> we are convinced it (kernel QUIC port) works well with SMB3.1.1
>> to servers which support QUIC, then move the quic code from fs/cifs to the /net
>> tree
> 
> The 4th step would then finally allocate a stable PF_QUIC which would be
> ABI stable.
> 
> metze

--
Chuck Lever