KTLS with zfs recv
Rodney W. Grimes
freebsd-rwg at gndrsh.dnsmgr.net
Sat Feb 27 14:10:23 UTC 2021
> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes <
> freebsd-rwg at gndrsh.dnsmgr.net> wrote:
>
> > > My understanding is that KTLS works very well with OpenSSL for sending,
> > but
> > > not as well for receiving, because there's nothing like a recvfile
> > > syscall. However, it works great for both send and receive with NFS,
> > where
> > > all the data remains in the kernel. What about zfs recv? A very common
> > > pattern is for an application to read from an SSL socket and then pipe
> > the
> > > data to zfs recv. For example, zrepl does that. Could zfs recv instead
> > > read directly from the KTLS socket, bypassing userspace? That could
> > > potentially save a _lot_ of cycles for a _lot_ of people.
> >
> > I did some patches and a short presentation at BSDCan that basically
> > shoves the whole zfs send and zfs recv process into the kernel, ie
> > it opens the sockets up, makes the connections, then the socket
> > is passed into the kernel(s) and it all runs in kernel mode.
> >
> >
> > https://www.bsdcan.org/2018/schedule/attachments/479_BSDCan-2018-zfs-send.pdf
> >
> > A few things need fixed like reversing who does the listen for
> > security reasons, but this feature is probably ready for prime
> > time.
> >
> > > -Alan
> >
> > --
> > Rod Grimes
> > rgrimes at freebsd.org
>
>
> That looks potentially useful, but it doesn't use encryption. Would it
> work if the socket had been opened by openssl with ktls?
Alan,
Should I revise the code to meet the state that was discussed
during the BSDCan talk so that it can be committed? Matt Aherns said
at the time he felt if I just reversed the listen/connect relationship
between send and recv that it addressed enough of the security concern
to be usable "on a local and well administered" network and would
probably be safe to import into upstream ZFS. (This was prior to
FreeBSD moving to openzfs.)
>From other discussion in this thread it does not sound difficult to
implement the KTLS end of it, but I doubt that would be portable
enough to upstream, maybe someone can speak to that issue?
--
Rod Grimes rgrimes at freebsd.org
More information about the freebsd-current
mailing list