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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 13 Jun 2021 14:08:23 -0400
From:   Alexander Aring <aahringo@...hat.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Stephen Hemminger <stephen@...workplumber.org>,
        Stefan Metzmacher <metze@...ba.org>,
        Steve French <smfrench@...il.com>,
        Aurélien Aptel <aaptel@...e.com>,
        Network Development <netdev@...r.kernel.org>,
        linux-nfs <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?

Hi,

On Sun, Jun 13, 2021 at 8:17 AM David Laight <David.Laight@...lab.com> wrote:
>
> From: Jakub Kicinski
> > Sent: 09 June 2021 17:48
> ...
> > > > I think two veth interfaces can help to test something like that,
> > > > either with a "fuse-like socket" on the other end or an user space
> > > > application. Just doing a ping-pong example.
> > > >
> > > > Afterwards we can look at how to replace the user generated socket
> > > > application with any $LIBQUIC e.g. msquic implementation as second
> > > > step.
> > >
> > > Socket state management is complex and timers etc in userspace are hard.
> >
> > +1 seeing the struggles fuse causes in storage land "fuse for sockets"
> > is not an exciting temporary solution IMHO..
>
> Especially since you'd want reasonable performance for quic.
>
> Fuse is normally used to access obscure filesystems where
> you just need access, rather than something that really
> needs to be quick.
>

or you have library dependencies like sshfs. That is the case in quic
for some parts of TLS (see TLS socket API). Sure it will not be the
final solution, that was never the intention. It is to establish a
kernel-API which will be replaced for a final in-kernel solution later
and not trying to solve all problems at once.

- Alex