From owner-freebsd-current@freebsd.org Fri Feb 26 18:53:16 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 4A61E54ADA2 for ; Fri, 26 Feb 2021 18:53:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 4DnJhD1Vkxz4jsK for ; Fri, 26 Feb 2021 18:53:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id l132so8913706qke.7 for ; Fri, 26 Feb 2021 10:53:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kOBJvVhAp43wwuFwle4ge8Sczy3WyM/TkQ9StsQ1tww=; b=tSvn6JSUHuybYHSl5+xJvv332uy9O7Ks2vnExqJ3t2zRYksLYg+wqsL6FoJk6mBqHB rnYh15lDQDZXyYkXxNCeN8//P66AW24X69jxfYGI33CDrjtpM6pj1wEEXK4/n8SGczhk YcpAYqu0uKBPi10yjHx0y0KgmV4kg/KkiD1ei0Nxk31nA1L5YcDs0ocyWy6dwrXAxPHV cbGmHmZMdfO7CDtW14UjYicDihCT6pH9xgwFgqDb9vKeZ2L78hHNTXwrmEpMq7937/Qw dsjt0o6X5XJ6U7vOOY1HQkHoAEE3bzBNHQmLWt1kjUTCdnikamPBlxAHb/2hWiBaSDPH JVnw== 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=kOBJvVhAp43wwuFwle4ge8Sczy3WyM/TkQ9StsQ1tww=; b=Y27YfUHOkvZRVnLL0Ju1Y0CPU/OVuaPtDtzXOrE4L8Y8i7rIYJXonOJIhSvfLiN7Fn WJyCTegPOAv3QOzGZZf+/FxEF8SnbAQNBktlNFFaGCvZC+/1BRTUBweLHBFTNJpNMGpM +8iGo0V6l1QtlM8cnlpQ84gUqtWGb08+bmdr2VzopMdqmF+HyiWj6EOvlTqBGFH+4rQw zzKdtGzSVFhdARlM/N4Zt6FgG/zD3XVuLuHEZzC0GxjulgTsEh4QTUTguDiNq3TLgLq9 BMiw8zpM7doGNfYS7vzGvVFG2e6EZ5XPODuh8REjbi7Hp4N4UL2eg13R4TN6mw9rrdz8 cAgA== X-Gm-Message-State: AOAM530L3+MatjlyGkxJQMz+tPpsFpQikxCSctHB/tWiehQf/01gd5rK Abvoro+2W5Ym8w/GWkCNZt5UkQAt8fqa7tg+axOo2qnoXTYjjg== X-Google-Smtp-Source: ABdhPJy9+qqtwZY/dYqmdhZ4k739xo8BBi0nxaqZJOMyU/6td2IXzH06vdHtg20Py7k4GDVtDRUqNAx4RZPXARJPcFo= X-Received: by 2002:a37:a151:: with SMTP id k78mr3959539qke.359.1614365595172; Fri, 26 Feb 2021 10:53:15 -0800 (PST) MIME-Version: 1.0 References: <202102261816.11QIGME9031366@gndrsh.dnsmgr.net> In-Reply-To: <202102261816.11QIGME9031366@gndrsh.dnsmgr.net> From: Warner Losh Date: Fri, 26 Feb 2021 11:53:03 -0700 Message-ID: Subject: Re: KTLS with zfs recv To: "Rodney W. Grimes" Cc: Alan Somers , FreeBSD CURRENT X-Rspamd-Queue-Id: 4DnJhD1Vkxz4jsK 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: Fri, 26 Feb 2021 18:53:16 -0000 On Fri, Feb 26, 2021 at 11:16 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? > > Yes, it should. Internally the zfs send and recv code just does reads > and writes to the socket, so what ever you setup for "connected" sockets > should work. > Yea, KTLS generally wants userland to do the initial negotiation and share the connection state before doing the bulk encryption in the kernel... Warner