From owner-freebsd-current@freebsd.org Thu Mar 11 01:17:54 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 90E5657E167 for ; Thu, 11 Mar 2021 01:17:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 4DwrfV3g5qz3G6Q for ; Thu, 11 Mar 2021 01:17:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f44.google.com with SMTP id n23so12798584otq.1 for ; Wed, 10 Mar 2021 17:17:54 -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=dE2ipxBtRwPtOyFB+xuzXwuRbGTtrgIYM5gdq1IIqLI=; b=bq4cSE+lzglToCPvGWQRSoMsO9E/T5Yxyl4Rbb1o1E5om003HRTaX+xKChcmiHdd53 oqSxUpXJwaQfe39QFAh7rjokfCkVTYGhDssKPR1F8qoz+7is5g48RrXse9WP5df0IXeW hK/YQ2F4/O5K8M6J834DuAo+9dyyEjPcAYLbia2QHucUGDd7ux6DqngeL2M5aP/V2eMx k6hLQ0542rjjBbFik1JOxfgjpK6+GyNJ5oJm7jQAdnBS4ff8BXpKUC9MOeK+BWEd+HUd LbcDXP0Eit2cjQXMxZ6Y9eFNOtoKJT0ii+5gNUv8iSOib5MwX3tVeUk7tHLofKsg5WQJ +Ifw== X-Gm-Message-State: AOAM532ivC32fdMk6dTUchWqSAWggIqWRM2CquHIDASRc8+2jPct2gWG cUJEtpbT1IEHUr7+KeKGPjVOwe37mPhnmpSIzLM= X-Google-Smtp-Source: ABdhPJx8zNfMTuQ6Zjx/IEeiqpb77CHCcq+0kEDEd9zG4NvCXreTJyb/twj83m8yFO8RHx1S26BsvYLiDilIGMV7pHE= X-Received: by 2002:a9d:76d4:: with SMTP id p20mr4911995otl.18.1615425473539; Wed, 10 Mar 2021 17:17:53 -0800 (PST) MIME-Version: 1.0 References: <20210311003136.GM56617@kduck.mit.edu> In-Reply-To: <20210311003136.GM56617@kduck.mit.edu> From: Alan Somers Date: Wed, 10 Mar 2021 18:17:42 -0700 Message-ID: Subject: Re: Getting started with ktls To: Benjamin Kaduk Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4DwrfV3g5qz3G6Q 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: Thu, 11 Mar 2021 01:17:54 -0000 On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > > the CPU utilization of applications like zrepl. But I have a few > questions: > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > > Libraries" section says "Applications using a supported library should > > generally work with ktls without any changes". These sentences seem to > be > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > necessary, but OpenSSL sets it automatically? > > Yes, OpenSSL sets it automatically for the builtin socket and connection > BIO classes. Applications using other BIO classes will need to do things > manually (or implement the appropriate _ctrl() parameters for their BIO > class). > > > * When using OpenSSL, the library will automatically call setsockopt(_, > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > application to tell if ktls is enabled on a particular socket or OpenSSL > > session? > > IIRC the lack of answer for this is part of why upstream OpenSSL doesn't > have specific KTLS tests enabled in the automated test suite. > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reason why it's not implemented? That might be the easiest way to check for the ktls status of an individual socket. > > > * From experiment, I can see that OpenSSL attempts to set > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > > From reading ktls_start and ossl_statem_server_post_work, it looks like > > maybe a single socket cannot have ktls enabled for both sending and > > receiving at the same time. Is that true? > > No. They just get enabled separately, since change_cipher_state() is > called separately for read and write transitions. > Apologies if I'm too ignorant, but what is a transition in SSL-speak? This is my first attempt at any kind of SSL programming. What I know from ktrace is that TCP_RXTLS_ENABLE never gets set. > > -Ben > > > Based on the man page and rmacklem's previous mailing list posts, I think > > this should be workable with minor modifications to the kernel and > libzfs. > > I just need to figure out how to use ktls first. > > > > -Alan > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" >