From owner-freebsd-arch@freebsd.org Sun Jan 14 23:59:44 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFF59E65FDF for ; Sun, 14 Jan 2018 23:59:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D48D873EAC for ; Sun, 14 Jan 2018 23:59:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.ysv.freebsd.org (Postfix) id D3FAFE65FDE; Sun, 14 Jan 2018 23:59:44 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3A8FE65FDD for ; Sun, 14 Jan 2018 23:59:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A882F73EAB; Sun, 14 Jan 2018 23:59:44 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w0ENxb33037010 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jan 2018 15:59:37 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w0ENxbfh037009; Sun, 14 Jan 2018 15:59:37 -0800 (PST) (envelope-from jmg) Date: Sun, 14 Jan 2018 15:59:37 -0800 From: John-Mark Gurney To: John Baldwin Cc: arch@freebsd.org Subject: Re: Ranting about OCF / crypto(9) Message-ID: <20180114235937.GS75576@funkthat.com> Mail-Followup-To: John Baldwin , arch@freebsd.org References: <3790717.UIxaijsHl3@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3790717.UIxaijsHl3@ralph.baldwin.cx> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 14 Jan 2018 15:59:38 -0800 (PST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 23:59:45 -0000 John Baldwin wrote this message on Wed, Jan 10, 2018 at 16:18 -0800: > While working on hooking the ccr(4) driver into our in-kernel crypto > framework (along with some out-of-tree patches to extend OpenSSL's > /dev/crypto engine to support AES-CTR/XTS/GCM and some further changes to > do zero-copy), I've run into several bumps / oddities in OCF. I'm probably > going to miss several of them, but here's at least a start of a list of > things. In some cases I have some suggestions on improvements. > > I will try to start with more broad / higher-level items first before > diving into minutiae: > > - OCF is over flexible and overly broad. Rather than supporting > arbitrary stacking of transforms (and arbitrary depths), I think we > should probably aim to support more specific workloads and support Many drivers don't fully support artitrary stacking... In fact, they will reorder to "make sense"... > them well. To my mind the classes of things we should support are > probably: > > - Simple block cipher requests. > - Simple "hash a buffer" requests. (Both HMAC and non-HMAC) > - IPSec-style requests (combined auth and encryption using > "encrypt-then-mac" with an optional AAD region before the > ciphertext). Note that geli requests fall into this type. > - TLS-style requests (using TLS's different methods of > combining auth and encryption methods when those are > separate) > - Simple compression / decompression requests. While this isn't > "crypto", per se, I do think it is probably still simpler to > manage this via OCF than a completely separate interface. We need to decide what we are using OCF for. Currently, due to how slow most hardware acceleration is, it's IPsec and GELI in the kernel, and then for embedded systems, OpenSSL for TLS acceleration... IMO, making it 100% generic is a terrible idea, and we should only support the above use cases... W/ the fact most modern processors are faster than most hardware acceleration, and I don't even know how many embedded systems are using OCF from userland as you have to configure the system to use crypto... > In terms of algorithms, I suspect there are some older algorithms > we could drop. Modern hardware doesn't offload DES for example. > Both ccr(4) and aesni(4) only support AES for encryption. We > do need to keep algorithms required for IPSec in the kernel, but > we could probably drop some others? I attempted to do this a few years back, and got significant push back... Please see the archives... > - To better support OpenSSL's engine, the /dev/crypto hash interface > should not require monotonic buffers, but support requests for > large buffers that span multiple requests (so you can do something > akin to the 'Init' / 'Update' (N times) / 'Final' model existing > software hashing APIs use). In particular, the bigger win for > hashing in hardware is when you can offload the hashing of a large > thing rather than small requests. > > - To better support OpenSSL's engine, the /dev/crypto hash interface > should support "plain" hash algorithms such as SHA* without an > HMAC. By default OpenSSL's engine interface does the HMAC-specific > bits (generating pads, etc.) in software and only defers to the > engine for the raw hash (e.g. if you use the HMAC() function from > libcrypto it will only ask the engine interface for a raw hash, > not for an HMAC hash). Already does for MD5 and SHA1. We have not added support for SHA-2 or SHA-3... #define CRYPTO_MD5 13 #define CRYPTO_SHA1 14 Yes, I know crypto(7) is lacking documentation for additional modes, but we didn't have any before I was working on it, so added what I could... > - To better support OpenSSL's engine, the /dev/crypto cipher > interface should also support non-monolithic buffers. The existing > engine does this now by copying the last block of the output data > out as a saved IV to use for a subsequent request, but it might be > nicer to be more formal here and return the IV to userland for > non-"final" cipher requests. > > - The interface between the crypto layer and backend drivers should > _not_ use integer session IDs. This is rediculously dumb and > inefficient. All the drivers have silly algorithms to try to manage > growable arrays that can be indexed by the returned session ID. > Instead, drivers should be able to return a 'void *' cookie when > creating a session and get that cookie pointer as an argument to > the 'process' and 'freesession' callbacks. Imagine if vnodes used > an i-node number rather than 'v_data' and you'd have the model OCF > uses. I don't mind if we have a kind of generic 'session' structure > that we export to drivers and pass in the callbacks and the drivers > get to use a 'foo_data' member of. > > - The interface to describe crypto requests needs to move away from > arbitrary linked lists of descriptors. We should just have a > single "session" structure that assumes you have one cipher and > one auth with a "mode" member to indicate the particular direction > / combination. Likewise, the description of a request needs to > have a similar assumption. The structures used by the /dev/crypto > ioctl's are a bit closer to what I think we should use compared to > the linked-list thing we have now. Related is that we should be > able to get rid of having the three separate "algorithms" for GCM > hashes. For AES-GCM one would just say they are using AES-GCM > and both the hash/tag and ciphertext would be valid inputs / outputs > with a single key. > > - To support non-monolithic buffers from the OpenSSL engine, crypto > requests to drivers also have to support non-monolithic buffers. > This means having a notion of a buffer that may be at the start, > middle, or end of a larger transformation (e.g. for hash only the > start gets the IPAD, only the end gets the OPAD and returns a > valid hash, etc., whereas for ciphers any non-end requests would > return the IV to use for the next request). > > For drivers that have buffer size limits, it would be nice to expose > those limits in the driver capabilities and depend on the upper layer > to "split" requests such as happens now for disk drivers. > > - For hashing algorithms we should support a "verify" mode in addition > to the current "compute" mode. The verify mode would accept a block > of data to hash along with an expected mac and return a success > / failure rather than an computed hash value. AES-GCM already works > this way for decryption, but this would extend that mode for other > hash algorithms (e.g. AES-CBC+SHA2-256-HMAC). Existing crypto > co-processors (e.g. ccr(4)) already support these types of requests. Please make sure that the compare is constant time for any verify modes. > Related is that we need to fix IPSec to treat EBADMSG errors from > descryption as auth failure rather than encryption failure (right > now AES-GCM auth failures are reported incorrectly in netstat -s > due to this). > > - Sessions for a combined cipher + hash should also be tied to a > specific way of combining the algorithms. Right now you can > create a session for AES-CBC with a SHA hash and the driver has no > way to know if you are going to do encrypt-then-mac or one of the > other variants. We should include this in the session (so a given > session can only be used for one type which is normally true anyway), > and drivers can then only claim to support combinations they > support. > > - The CRD_F_IV_PRESENT flag should be removed and replaced with > a CRD_F_IV_INJECT flag which means "inject the IV". Right now > the _lack_ of CRD_F_IV_PRESENT for encryption (but not decryption!) > requests means "inject the IV". It would be clearer to just have > a flag that is only set when you want the driver to take the > action. > > - Speaking of IV handling, drivers have to do some extra handling for > IVs including possibly generating them. I think the idea is that > some co-processors might support generating IVs, but most of the > drivers I've looked at just end up duplicating the same block of > code to call arc4rand() for encryption requests without > CRD_F_IV_EXPLICIT. I don't believe Linux tries to support this and > instead always supplies an IV to the driver. I'd rather we do that > and only depend on a flag to indicate where the IV is (crd_iv vs > in the buffer). > > - The API for copying data to/from crypto buffers is a bit obtuse and > limiting. Rather than accepting the crypto operation ('crp') as > a parameter to describe the crypto buffer, the crypto_copyback() > and crypto_copydata() functions accept various members of that > function explicitly (e.g. crp_flags and crp_buf). However, in my > experiments with zero-copy AES-GCM via /dev/crypto and OpenSSL it > was convenient to store the AAD in a KVA buffer in the 'crp' and > the payload to transform in an array of VM pages. However, for > this model 'crp_buf' is useless. I ended up adding a wrapper API > 'crypto_copyto' and 'crypto_copyfrom' which accept a 'crp' directly. > Linux's API actually passes something akin to sglist as the > description of the buffers in a crypto request. > > - We need to not treat accelerated software (e.g. AES-NI) as a > hardware interface. Right now OCF's model of priorities when > trying to choose a backend driver for a session only has two > "levels" software vs hardware and aesni(4) (and the ARMv8 variant) > are lumped into the hardware bucket so that they have precedence > over the "dumb" software implementation. However, the accelerated > software algorithms do need some of the same support features of > the "dumb" software implementation (such as being scheduled on a > thread pool to use CPU cycles) that are not needed by other "hardware" > engines. OCF needs to understand this distinction. > > - Somewhat related, we should try to use accelerated software when > possible (e.g. AES-CBC with SHA) doesn't use AES-NI unless the > CPU supports accelerated SHA. Ideally for this case we'd still > use AES-NI for the AES portion along with the software SHA > implementation (and we'd do it one pass over the data rather than > two when possible). Intel has lots of assembly for combined modes, including a pipelined mode for AES-CBC+SHA2 that allows 4 streams to be processed in effectively the same time as one stream... Being able to make use of these is cool, but IMO, w/ AES-GCM, or AES-GCM-SIV is a better solution than trying to shoe horn in old algorithms like this... If someone really needs it, they can pay for it, but IMO, lets get the most bang for the buck... > - Sometimes a crypto driver might need to defer certain requests to > software (e.g. ccr(4) has to do this for some GCM requests). In > addition, there are some other cases when we might want requests > from a single session to be sent to different backends (e.g. you > may want to use accelerated software for requests below a certain > size, and a crypto engine for larger requests. You might also want > to take NUMA into account when choosing which backend crypto engine > to dispatch a request to.) To that end, I think we want to have the > ability for a single OCF session to support multiple backend > sessions. > > One use case is that if I as a driver can't handle a request I'd like > to be able to fail it with a special error code and have the crypto > later fall back to software for me (and to use accelerated software if > possible). Right now ccr(4) duplicates the "dumb" software for GCM > requests it can't handle explicitly. > > Another use case might be failover if a hardware engine experiences > a hardware failure. In theory it should be possible to fail over > to a different driver at that point including resubmitting pending > requests that weren't completed, and it should be possible (I think) > to manage this in the crypto framework rather than in consumers like > IPSec and GELI. > > Load distribution among backends might be another case to consider > (e.g. GELI or ZFS encryption once that lands) if you have long- > running sessions that spawn lots of self-contained requests. > > Note that if we want to spawn additional backend sessions on the fly > (e.g. only create a software fallback session on demand if a driver > fails a request with the "use software" magic error code), we will > have to keep per-session state such as keys around. We probably > already do that now, but this would definitely require doing that. > > One concern with some of these changes is that there are several drivers > in the tree for older hardware that I'm not sure is really used anymore. > That is an impediment to making changes to the crypto <-> driver interface > if we can't find folks willing to at least test changes to those drivers > if not maintain them. I have recently obtained a good amount of this hardware from various donations... hifn, via padlock, and possibly ubsec, I'd have to check.. IMO, I'd like to see us deprecate most of these old drivers as they are mostly too slow, or even if you can find a system to put them in, it's overall faster/energy effecient to go w/ newer hardware that is faster and run pure software... Again, lease read the archives for more of this discussion... > This is all I could think of today. What do other folks think? I'd like to see a full redesign of the system, but I also don't know how many other third party utilities depend upon /dev/crypto that are not in tree... I'm willing to meet w/ people to discuss/design this... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Mon Jan 15 00:06:40 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4418CE68A0B for ; Mon, 15 Jan 2018 00:06:40 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 27C6B74437 for ; Mon, 15 Jan 2018 00:06:40 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.ysv.freebsd.org (Postfix) id 27151E68A0A; Mon, 15 Jan 2018 00:06:40 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26A65E68A09 for ; Mon, 15 Jan 2018 00:06:40 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 060D074436; Mon, 15 Jan 2018 00:06:39 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w0F06crQ037148 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jan 2018 16:06:38 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w0F06cEI037147; Sun, 14 Jan 2018 16:06:38 -0800 (PST) (envelope-from jmg) Date: Sun, 14 Jan 2018 16:06:38 -0800 From: John-Mark Gurney To: "Bjoern A. Zeeb" Cc: Benjamin Kaduk , arch@freebsd.org Subject: Re: Ranting about OCF / crypto(9) Message-ID: <20180115000638.GT75576@funkthat.com> Mail-Followup-To: "Bjoern A. Zeeb" , Benjamin Kaduk , arch@freebsd.org References: <3790717.UIxaijsHl3@ralph.baldwin.cx> <20180111055620.GO72574@kduck.kaduk.org> <8C6BFBB0-3323-4DC8-BF23-B27D0235256D@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C6BFBB0-3323-4DC8-BF23-B27D0235256D@lists.zabbadoz.net> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 14 Jan 2018 16:06:38 -0800 (PST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 00:06:40 -0000 Bjoern A. Zeeb wrote this message on Thu, Jan 11, 2018 at 13:07 +0000: > On 11 Jan 2018, at 5:56, Benjamin Kaduk wrote: > > >> In terms of algorithms, I suspect there are some older algorithms > >> we could drop. Modern hardware doesn't offload DES for example. > >> Both ccr(4) and aesni(4) only support AES for encryption. We > >> do need to keep algorithms required for IPSec in the kernel, but > >> we could probably drop some others? > > > > Yes, it's probably time for DES to go. Maybe others as well. > > There sadly still is a lot of commercial gear out there that still > requires single-DES. Even 3DES is effectively broken: https://sweet32.info/ and does it even make sense to support acceleration of DES? Does anyone realistically depend upon hardware acceleration of it? I'd be surprised if anyone does. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Mon Jan 15 00:08:37 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8744E68BD9 for ; Mon, 15 Jan 2018 00:08:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8C65D74543 for ; Mon, 15 Jan 2018 00:08:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8BBC1E68BD7; Mon, 15 Jan 2018 00:08:37 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B688E68BD6 for ; Mon, 15 Jan 2018 00:08:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F65574542; Mon, 15 Jan 2018 00:08:37 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w0F08aOa037176 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jan 2018 16:08:36 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w0F08aBH037175; Sun, 14 Jan 2018 16:08:36 -0800 (PST) (envelope-from jmg) Date: Sun, 14 Jan 2018 16:08:36 -0800 From: John-Mark Gurney To: John Baldwin Cc: Benjamin Kaduk , arch@freebsd.org Subject: Re: Ranting about OCF / crypto(9) Message-ID: <20180115000836.GU75576@funkthat.com> Mail-Followup-To: John Baldwin , Benjamin Kaduk , arch@freebsd.org References: <3790717.UIxaijsHl3@ralph.baldwin.cx> <20180111055620.GO72574@kduck.kaduk.org> <1848677.SMV3i9kbhA@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1848677.SMV3i9kbhA@ralph.baldwin.cx> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sun, 14 Jan 2018 16:08:36 -0800 (PST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 00:08:37 -0000 John Baldwin wrote this message on Thu, Jan 11, 2018 at 09:41 -0800: > > > - Simple compression / decompression requests. While this isn't > > > "crypto", per se, I do think it is probably still simpler to > > > manage this via OCF than a completely separate interface. > > > > Probably, though perhaps less so after the removal of arbitrary > > stacking depths. And mixing compression with encryption has its own > > risks, of course. > > I probably think you wouldn't mix but would either do compression, auth, > hash, or auth+enc. NetBSD's /dev/crypto does support stacking > compression + auth + enc in a single ioctl, but it doesn't provide any > way to control the ordering so in practice I think it was just a way to > permit offloading compression alone. Never makes sense to do compression after enc, so it's really what order auth and enc should happen in.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Tue Jan 16 09:50:00 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EE81EB87E0 for ; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8459F70BA3 for ; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: by mailman.ysv.freebsd.org (Postfix) id 83B9BEB87DF; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 836AEEB87DE for ; Tue, 16 Jan 2018 09:50:00 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CF5E70BA1; Tue, 16 Jan 2018 09:49:59 +0000 (UTC) (envelope-from emeric.poupon@stormshield.eu) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 6FD0E3760358; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 61A60376096D; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OYNX_nCy1DfY; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Received: from work.stormshield.eu (localhost [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 4F5D43760358; Tue, 16 Jan 2018 10:50:47 +0100 (CET) Date: Tue, 16 Jan 2018 10:50:47 +0100 (CET) From: Emeric POUPON To: John Baldwin Cc: arch@freebsd.org Message-ID: <973472132.3159693.1516096247163.JavaMail.zimbra@stormshield.eu> In-Reply-To: <3790717.UIxaijsHl3@ralph.baldwin.cx> References: <3790717.UIxaijsHl3@ralph.baldwin.cx> Subject: Re: Ranting about OCF / crypto(9) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Thread-Topic: Ranting about OCF / crypto(9) Thread-Index: 86xZP1caLjQ7WbpOKF6kTUpF0Q3CTA== X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 09:50:00 -0000 Hello, > - We need to not treat accelerated software (e.g. AES-NI) as a > hardware interface. Right now OCF's model of priorities when > trying to choose a backend driver for a session only has two > "levels" software vs hardware and aesni(4) (and the ARMv8 variant) > are lumped into the hardware bucket so that they have precedence > over the "dumb" software implementation. However, the accelerated > software algorithms do need some of the same support features of > the "dumb" software implementation (such as being scheduled on a > thread pool to use CPU cycles) that are not needed by other "hardware" > engines. OCF needs to understand this distinction. > > - Somewhat related, we should try to use accelerated software when > possible (e.g. AES-CBC with SHA) doesn't use AES-NI unless the > CPU supports accelerated SHA. Ideally for this case we'd still > use AES-NI for the AES portion along with the software SHA > implementation (and we'd do it one pass over the data rather than > two when possible). Indeed it would make sense to extend the software driver to make use of available software acceleration. From IPSec, this would allow to accelerate the encryption part without accelerating the authentication part, and it is still a very common use case. Actually, we have some patches to do that, maybe it would make sense to try to distribute them? This would require quite a significant amount of work though. > This is all I could think of today. What do other folks think? Well, the batch mode and its queue is questionable. Indeed, when using several hardware drivers, having a single process trying to dispatch the crypto jobs to the drivers and calculating the CRYPTO_HINT_MORE flag sounds inefficient. Maybe we would need a dedicated queue/thread per driver if we really want the batch mode to be effective? Furthermore, hardware drivers often already manage internal queues for jobs. I guess the only benefit of the batch mode would be to allow a lot of crypto requests to be queued in the framework and prevent the consumers to deal with the crypto requests they don't manage to enqueue? From owner-freebsd-arch@freebsd.org Thu Jan 18 21:25:41 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B4C9EC41B2 for ; Thu, 18 Jan 2018 21:25:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2BC9181E4B for ; Thu, 18 Jan 2018 21:25:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-wm0-x241.google.com with SMTP id b141so24799170wme.1 for ; Thu, 18 Jan 2018 13:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=HKZugvXdDmEYitBxcpc45o8ygHa0FFSe63nxQVRXcis=; b=xpQbG4b1Oba8q9fcB2G5oJOfVI/Qe/1No565WO3c5j7ujJNqn+to7YZ3pwdp8WgqbO T8HZBeHffaY9N9S9axvtlzyac4pSiFNVyI1wyHMcl8FIeQN5arIQWkeUVAuCXQ2/QgRa L7c16bpLQQacTaqFcvnShX8H2unGMMtZmS+oNVSyXbFtMuEZaPUdorbv0RH1tnmrf9TX oRLsvElaZM9tH9B9O5tgXLAmwwmEc4gJZ+mfTrpJfDA5h+NnB1KoQZRKIffbBYq88k1q UbbyHhmjVShOhL7y0HmykdXDeZCRn78AAcK/Wz3/sVS0m+J1MH8PHOsuADxY/NF5jaw+ n8vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=HKZugvXdDmEYitBxcpc45o8ygHa0FFSe63nxQVRXcis=; b=kiZ7GSZ8JQHXiXiUAjfLgevygCcIzdR4iGstg2sK28IKDe4UYFnKA/19BAqBLm+o72 qPEpH3HI+eU8Z4grbs5gp+xvgFBajE3wXf7wMmiLoYbuRDoSQaz6j+Tm+6XEnfOfqZES 1YYkb0yldGv1wD0Joibil5zKL4tNdkvaZgIZxk5d6AG8jxqPahXCs6bmLujNFMyAkPuw oeetNaPZFDfJC6I5EimoapnmIsdUurHZOyIxsYnfg8xjlk/zV5ApqAUeduGeJIb0cIN5 xCxyglSqFrAxjJGFBmjmaeOKIHeaj7PCUJ8+qG+Exm5LB2/bWotongm/4dcMkMX2rsp2 7zuQ== X-Gm-Message-State: AKwxyte4IDDNLNe7V8i2vDW3mDISOquMzrYWGVDZWRUZc4pJUyrjcbqF eaEhKsU2i8COiGub5BGaEjKhMt3fC8VsCuKKjuW+jeue X-Google-Smtp-Source: ACJfBouoMGf/b2SotWy6B9pXRZ2AteaYlshryYrgJ8PlsWdfSYklQSLAD5N9IuVyEkMYBP9HuxkM0jRU4td3W+s8WDM= X-Received: by 10.80.186.161 with SMTP id x30mr9869822ede.138.1516310739405; Thu, 18 Jan 2018 13:25:39 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.80.195.12 with HTTP; Thu, 18 Jan 2018 13:25:39 -0800 (PST) X-Originating-IP: [50.253.99.174] From: Warner Losh Date: Thu, 18 Jan 2018 14:25:39 -0700 X-Google-Sender-Auth: 8ymnbcSn-JMizrhpy5UFYeF_-Bo Message-ID: Subject: Style(9) clarification: c99 initializers To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 21:25:41 -0000 I'd like to make the following change to style(9) to codify the current momentum towards using c99 designated initializers where it makes sense: diff --git a/share/man/man9/style.9 b/share/man/man9/style.9 index f008a7d613e..75dba71830f 100644 --- a/share/man/man9/style.9 +++ b/share/man/man9/style.9 @@ -324,6 +324,10 @@ Userspace code should include while kernel code should include .In sys/types.h . .Pp +Likewise, the project is moving to using the +.St -isoC-99 +designated initializers when it makes sense to do so. +.Pp Enumeration values are all uppercase. .Bd -literal enum enumtype { ONE, TWO } et; Comments? Warner From owner-freebsd-arch@freebsd.org Thu Jan 18 21:30:19 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C63EEC44D1 for ; Thu, 18 Jan 2018 21:30:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A38C382158 for ; Thu, 18 Jan 2018 21:30:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-wm0-x232.google.com with SMTP id t74so24811638wme.3 for ; Thu, 18 Jan 2018 13:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=X1pQIlShsdeo2yPBYGUcklub6RmOjqADqFu8fNuoinY=; b=jzTJLydmUhOysyeqZ8tpW23U3QpTOOJWyTYT5PwsTX459fH3YpqNnQnC3Ns7p7RBni 1flTGBhwbNJHPAMgeSiBcfBS3Bha5lg7DTnn+d34zHz7EcMAVDCPn1iAmjGEXtHZfUxL w2QZ2y598hTo8YXMlULfOGOoHalXyTw7+8jTmHpZgDqNhuRtFTst8osJ9dCuOAT5Vf5B P8zFZ98WvJBZLDEWTIXWoV7+xHm5HuKooBbiejXH/adWknu7qVeQsarWZHVyP+jp2f2Y 9lTcPP0uefcNnV8OPxN0HHCv/HYR9a4nZt7Z6Vz4+cbrBLZmR1AeiHjIPZgSW4qCMqQn MmOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=X1pQIlShsdeo2yPBYGUcklub6RmOjqADqFu8fNuoinY=; b=IyQYdXAcfTMHVgt3q2j4O+zG/IgRgmcOIqzB5g+qqQnzjpLWDei3Ws+j30OxFkfY9E lTcEXnJ5A86PCYlj23kIEHpknK8YzshM7adfATLd2jhSvAyelHU+1baZW8J70srMCQXU l9tN4T+2XVLclwrQ9VmvO8a8I8VLNjNf/xMhF8GzCHrZEtoxP7anR+nZs+LI5ZZeWSQI cqk6ZfU7LL9tpxdpxGgTdsLj1/H2r4otQCZKhXO6+BjU/uI6PDWgBAiVXGzX2O79nyKb 7QpC4V7rCBaJ+ip44bdvCT6vSlecjeKoyhqrLlW8KTjt12YCMf+rVMIjN7S0a9VhMoJn 5b6w== X-Gm-Message-State: AKwxytd0HheSbENzX9DwavMGSExjIhz9MfjjzcWYUY+xagw+QEM3AaUy 1dLwi7Dx3JEB8+pYrjBb9wka5KAZemeRozJEtps5WyXw X-Google-Smtp-Source: ACJfBovl2HlocYgyGK9kdwCdjn6j1hXdkZ7wmA53/yWYoRP7i9AbhiPPmuuhE0TD9KSuHERNH3VGjCDNv30hxfQBUO4= X-Received: by 10.80.190.9 with SMTP id a9mr9676103edi.258.1516311016883; Thu, 18 Jan 2018 13:30:16 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.80.195.12 with HTTP; Thu, 18 Jan 2018 13:30:16 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: From: Warner Losh Date: Thu, 18 Jan 2018 14:30:16 -0700 X-Google-Sender-Auth: AUW__bLP263N65KDNk3ucNYzRhQ Message-ID: Subject: Re: Style(9) clarification: c99 initializers To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 21:30:19 -0000 I've opened https://reviews.freebsd.org/D13975 for this. Warner On Thu, Jan 18, 2018 at 2:25 PM, Warner Losh wrote: > I'd like to make the following change to style(9) to codify the current > momentum towards using c99 designated initializers where it makes sense: > > diff --git a/share/man/man9/style.9 b/share/man/man9/style.9 > index f008a7d613e..75dba71830f 100644 > --- a/share/man/man9/style.9 > +++ b/share/man/man9/style.9 > @@ -324,6 +324,10 @@ Userspace code should include > while kernel code should include > .In sys/types.h . > .Pp > +Likewise, the project is moving to using the > +.St -isoC-99 > +designated initializers when it makes sense to do so. > +.Pp > Enumeration values are all uppercase. > .Bd -literal > enum enumtype { ONE, TWO } et; > > Comments? > > Warner >