From owner-freebsd-current@freebsd.org Sat Feb 27 15:20:35 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 70F70549C83 for ; Sat, 27 Feb 2021 15:20:35 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DnqwM2lGtz3FYF for ; Sat, 27 Feb 2021 15:20:35 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f50.google.com with SMTP id p6so2907423oot.2 for ; Sat, 27 Feb 2021 07:20:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qmGDpvSwPb5olKl47kLbYaqoj8Xzr/hv0hcQZYknrUQ=; b=GjBOlPkZ01cBwpIxYUP5T2p1sq8jDGneatPNpCbQF9Rd2YDFE9bfQZpUcTTPOI9Nk5 Mzh3uPXKhKK6xAEKnmXTl85Vpt1MWNbYwwfuDYFDRrTDWT4I8JMCvGFn2JOyo9YU9K8S jX38/DIDnlmuINqWWsQZm92/na16sMlpQsF7+8Ryi6J18CbnvxOFSdawJ5CfED+bXTxM u9Y3HpOfSkzh4Jm93+zvHxfPFpR4rHSgS6j1Gi/+oigr7F765OK5v5Lk34ZoIfPyFOYD LQf3uDRCsp5J9JeA5R8e0tGuIAbWwG6PSg4eC+9G9OdWLb/dr/XxGwSZPga2VAe1CrCp BivA== X-Gm-Message-State: AOAM533at9lbTLd2BKEThNIaYgqi/0XRhLQSfJEDpI7rFIE/ZwNZV3OY 3ProU2TJL25pgry94Hc+/BF44H9JHOe3qbPy0OA= X-Google-Smtp-Source: ABdhPJwXqO7THGz+7qeWVAo1OHdhtKU9uXtM6/q02hyRxi+OjdZl6vzwa2DIOKqppNfpdN/RGKlSwKSny6ZFD90OcaU= X-Received: by 2002:a4a:e939:: with SMTP id a25mr6258036ooe.44.1614439234191; Sat, 27 Feb 2021 07:20:34 -0800 (PST) MIME-Version: 1.0 References: <202102271410.11REAEZm034986@gndrsh.dnsmgr.net> In-Reply-To: <202102271410.11REAEZm034986@gndrsh.dnsmgr.net> From: Alan Somers Date: Sat, 27 Feb 2021 08:20:23 -0700 Message-ID: Subject: Re: KTLS with zfs recv To: "Rodney W. Grimes" Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4DnqwM2lGtz3FYF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2021 15:20:35 -0000 On Sat, Feb 27, 2021 at 7:10 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > 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 Rod, it would be great if we can get that code committed. I'll try to come up with a OpenSSL->zfs recv POC program next week. And I think we should try to upstream it to OpenZFS, too. They aren't strict about portability; plenty of OS-specific features have made it into their repo. -Alan