From owner-svn-src-all@freebsd.org Mon Apr 13 16:56:21 2020 Return-Path: Delivered-To: svn-src-all@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 C37C42C3A02; Mon, 13 Apr 2020 16:56:21 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 491FBY4ZY6z3Q2C; Mon, 13 Apr 2020 16:56:21 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-164.local (unknown [IPv6:2601:648:8881:1e90:d8bf:7fe5:771e:58a8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 0DFC02FC38; Mon, 13 Apr 2020 16:56:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) 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: d@delphij.net, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <202003271825.02RIPOmR010857@repo.freebsd.org> <9c343572-5bf6-7047-f435-8e3fcffa8f8e@delphij.net> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <36ec45df-1217-8709-61ec-9c335dee5736@FreeBSD.org> Date: Mon, 13 Apr 2020 09:56:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <9c343572-5bf6-7047-f435-8e3fcffa8f8e@delphij.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 16:56:21 -0000 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.) Also, while AES-NI instructions are faster than plain C, they are still very much software rather than an engine like QAT or ccr(4). They run synchronously using host CPU cycles rather than async on a separate co-processor. This means that if you tweak the various geli sysctls for batching vs non-batching, etc. you need to make the same choices for both accelerated software and "plain" software vs possibly different choices for an async co-processor. -- John Baldwin