Date: Sat, 27 Feb 2021 06:10:13 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Alan Somers <asomers@freebsd.org> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: KTLS with zfs recv Message-ID: <202102271410.11REAEZm034986@gndrsh.dnsmgr.net> In-Reply-To: <CAOtMX2geavU-dvoT_WhifHh6ijmf%2BwSCkV52k89JWn8DgjdArA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Feb 26, 2021 at 9:24 AM Rodney W. Grimes < > freebsd-rwg@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@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@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202102271410.11REAEZm034986>