From owner-svn-src-head@freebsd.org Mon Apr 13 19:31:50 2020 Return-Path: Delivered-To: svn-src-head@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 9EE612C73CA for ; Mon, 13 Apr 2020 19:31:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf41.google.com (mail-qv1-xf41.google.com [IPv6:2607:f8b0:4864:20::f41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 491Jdx4fXcz45b5 for ; Mon, 13 Apr 2020 19:31:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf41.google.com with SMTP id q73so4997561qvq.2 for ; Mon, 13 Apr 2020 12:31:49 -0700 (PDT) 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; bh=/AYDxP2Q3Mh49CQR1w0RDODJGLYGfShpBU3bQtJYqXI=; b=q+uoVCekLK1jHgdPoJSygRef3x9hPxN86pXvTDETJrQWSombwxnivM0ShxZ7IZqzQt YF3uadninlPG+P/ORuCpH7m8+nbmE+XV6Wv/lSjHORO9c8l1DK7Dokkv1lUKNPUhEm0H 6mbkInTPu2+6rUmeKxEtN3HCbWmTsscC155FCm7OzlRTdqDBDX2uTtl1x/j56WrLWkaV 0P6WLLGNl4WvtbHfyOpyNLIBQCjiHGXn68zPV+XB/xo8dA8raS8iO1neA1o1Ex1Qv2s3 Piya1cYSHmladg4nyOecAAQJtfML4fXGRxMXSCX60jd9UNFcUKT3c52hQfBFgFJWi40G mrTg== 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; bh=/AYDxP2Q3Mh49CQR1w0RDODJGLYGfShpBU3bQtJYqXI=; b=AyZX+5j1Y5kNXKkki+IZ768JN8oVp2U8PtTAT9CKXackTiWy9edbmcDXySJ4zegZLd TyShNIk+LI0hHhzz+GYNy4D5nBLSkOixNiJoRxtUepT7lC7Buhv82nmx9XVEFHP9zRUz Tw4ATb74Il+HrdewXIRMRcajhtpFNHbYrmBS+6N3E1FErCiUJKZqnS+SksAZlPy9WGGc 9SAMfyR+70EJrujfP4bt2T2n8QgeR0H8dsbcrL8r1pWUhmb3AdOxSMB2vo3zztGS8pf/ xkF7HkM6PWJ/G7fNqrG3VQ1oclBq98C+LdLJ9fu9Gej0oSLzU4AVkbRlD5KDoBorgrJq aZvg== X-Gm-Message-State: AGi0PuZZQbsearzndRMAXgoKmDHftzdG8CrAYaz7ly8WHX3VmUWbMXQ/ DK2OvW3jCERQyC0ZKR2PXXFm/oZQn11H3G91iYEHUWBH X-Google-Smtp-Source: APiQypJJwpns9hkEeyvoWKcvK3O0Tv/s+ipNQgXkbS/rSjyqRESq6obWTtrFq/l3vWpFue+u47tQtdHKAc7xmUcajSs= X-Received: by 2002:a0c:e105:: with SMTP id w5mr2335124qvk.118.1586806307998; Mon, 13 Apr 2020 12:31:47 -0700 (PDT) MIME-Version: 1.0 References: <202003271825.02RIPOmR010857@repo.freebsd.org> <9c343572-5bf6-7047-f435-8e3fcffa8f8e@delphij.net> <36ec45df-1217-8709-61ec-9c335dee5736@FreeBSD.org> <20200413192202.GQ4213@funkthat.com> In-Reply-To: <20200413192202.GQ4213@funkthat.com> From: Warner Losh Date: Mon, 13 Apr 2020 13:31:36 -0600 Message-ID: Subject: Re: svn commit: r359374 - in head: . share/man/man4 share/man/man7 share/man/man9 sys/crypto/aesni sys/crypto/armv8 sys/crypto/blake2 sys/crypto/ccp sys/crypto/via sys/dev/cesa sys/dev/cxgbe sys/dev/cx... To: John Baldwin , Xin LI , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 491Jdx4fXcz45b5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=q+uoVCek; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f41) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.15 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.16)[ip: (0.00), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 19:31:50 -0000 On Mon, Apr 13, 2020 at 1:22 PM John-Mark Gurney wrote: > John Baldwin wrote this message on Mon, Apr 13, 2020 at 09:56 -0700: > > On 4/12/20 1:08 PM, Xin Li wrote: > > > > > > > > > On 3/27/20 11:25 AM, John Baldwin wrote: > > > [...]> - Drivers no longer register a list of supported algorithms. > This > > >> doesn't quite work when you factor in modes (e.g. a driver might > > >> support both AES-CBC and SHA2-256-HMAC separately but not combined > > >> for ETA). Instead, a new 'crypto_probesession' method has been > > >> added to the kobj interface for symmteric crypto drivers. This > > >> method returns a negative value on success (similar to how > > >> device_probe works) and the crypto framework uses this value to > pick > > >> the "best" driver. There are three constants for hardware > > >> (e.g. ccr), accelerated software (e.g. aesni), and plain software > > >> (cryptosoft) that give preference in that order. One effect of > this > > >> is that if you request only hardware when creating a new session, > > >> you will no longer get a session using accelerated software. > > >> Another effect is that the default setting to disallow software > > >> crypto via /dev/crypto now disables accelerated software. > > > > > > For user-visible interface, it seems like we are essentially treating > > > "accelerated software" like AES-NI the same way of plain software. For > > > example, geom_eli would now say: > > > > > > GEOM_ELI: Encryption: AES-XTS 128 > > > GEOM_ELI: Crypto: software > > > > > > Instead of: > > > > > > GEOM_ELI: Encryption: AES-XTS 128 > > > GEOM_ELI: Crypto: hardware > > > > > > When AES-NI is used (which is because we only have two bits to > represent > > > hardware and software, and have gave neither bits clear with its own > > > meaning (use specific driver)). > > > > > > If we are not going to add a new bit to represent accelerated software, > > > why are they categorized as software providers? Technically, all these > > > still requires hardware that implements the cryptographic primitives to > > > work, and it's much easier for system administrators if we expose the > > > fact that they are using some kind of acceleration than asking them to > > > run DTrace etc. to find out. Personally, I think it's probably better > > > to change the notion to either "accelerated" (by either hardware or > > > software) and "software"... > > > > The only case where this is visible is in fact GELI (there is no printf > > for IPsec or KTLS). For /dev/crypto using aesni.ko is a bug, not a > > feature, as any such software would be much better off using AES-NI in > > userland instead of round-tripping through the kernel. We could add a > > bit to appease the GELI printf, or we could just kill the GELI > > printf. I think a more useful approach would probably be to kill the > > GELI printf and instead add something less GELI-specific such as > > counters of active sessions for the various cryptographic drivers that > > would show which drivers are in use for any in-kernel crypto. This > > approach also lends itself to supporting a more flexible API where a > > single crypto session might be backed by multiple drivers where a > > binary hardware / software setting might not even make sense as you > > might have a mix. (I know of other out-of-tree crypto use cases that > > experimented with splitting in-kernel crypto workloads between an > > async co-processor and AES-NI.) > > As long as there remains some what to warn the user that when they've > mounted a geli volume that they're using slow crypto, I'm fine... > > We have done a bad job on doing the right thing, and I'm afraid that > removing this print w/o doing something to address it will go from > FreeBSD already not doing the right thing, but to not allowing the user > to know that FreeBSD isn't doing the right thing. > > Even a simple print in the crypto driver when the processor supports > AES-NI, but the aesni module isn't loaded would be useful.. > > Without the geli print, it's likely articles, like the recent Anandtech, > will think FreeBSD's encrypted volumes are slow when it's just a failure > for us to do the correct thing. > > I haven't looeked at the new code, but the resaon that aesni.ko was > considered a hardware vs software device was that the existing crypto > framework didn't have a well to tell the two apart, and it wasn't > possible to select the aesni.ko routines over the software routines > in a reliable manner. > Seems to me this isn't a binary, but a triary: software, CPU assist, hardware offload. but that maybe over-complicating things... Warner