Re: KTLS with zfs recv

> 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