From owner-freebsd-arch@freebsd.org Mon Aug 5 10:19:32 2019 Return-Path: Delivered-To: freebsd-arch@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 C8EECBFC4C for ; Mon, 5 Aug 2019 10:19:32 +0000 (UTC) (envelope-from fabien.thomas@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 462DJz4k1Yz4TFD; Mon, 5 Aug 2019 10:19:31 +0000 (UTC) (envelope-from fabien.thomas@stormshield.eu) Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 554D43767C1F; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 452533767C21; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) 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 gbpqQniMNSkE; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) Received: from [192.168.129.1] (support1.stormshield.eu [91.212.116.2]) by work.stormshield.eu (Postfix) with ESMTPSA id 25DD83767C1F; Mon, 5 Aug 2019 12:19:14 +0200 (CEST) From: "Fabien Thomas" To: "John Baldwin" Cc: freebsd-arch@freebsd.org Subject: Re: Open Crypto Framework Changes: Round 1 Date: Mon, 05 Aug 2019 12:19:13 +0200 X-Mailer: MailMate Trial (1.12.5r5635) Message-ID: <9E88949D-92D5-40EA-8ACA-B10E56102476@stormshield.eu> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 462DJz4k1Yz4TFD X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fabien.thomas@stormshield.eu has no SPF policy when checking 91.212.116.1) smtp.mailfrom=fabien.thomas@stormshield.eu X-Spamd-Result: default: False [3.32 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.89)[0.887,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[stormshield.eu]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.974,0]; IP_SCORE(0.56)[ip: (1.48), ipnet: 91.212.116.0/24(0.74), asn: 49068(0.59), country: FR(-0.01)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.116.212.91.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2019 10:19:32 -0000 Hi John, Good news to know that you are working on it. > A while back I ranted about what I perceived to be several issues with > our in-kernel framework. I've been working on a first round of=20 > changes > over the past several months and believe I've gotten far enough to be > a first milestone that's probably suitable for merging. At this point > what I would most appreciate is design review on what I've done so far > (though an eye towards the future wouldn't hurt). I have more changes=20 > I > think I'd like to make, but this is a big enough chunk to chew on for > now. > > The code: > > https://github.com/freebsd/freebsd/compare/master...bsdjhb:ocf_rework > > Summary of changes: > > - The linked list of cryptoini structures used in session > initialization is replaced with a new flat structure: struct > crypto_session_params. This session includes a new mode to define > how the other fields should be interpreted. Available modes > include: > > - COMPRESS (for compression/decompression) > - CIPHER (for simple encryption/decryption) > - DIGEST (computing and verifying digests) > - AEAD (combined auth and encryption such as AES-GCM and AES-CCM) > - ETA (combined auth and encryption using encrypt-then-authenticate) > > Additional modes could be added in the future (e.g. if we wanted to > support TLS MtE for AES-CBC in the kernel we could add a new mode > for that. TLS modes might also affect how AAD is interpreted, etc.) > > The flat structure also includes the key lengths and algorithms as > before. However, code doesn't have to walk the linked list and > switch on the algorithm to determine which key is the auth key vs > encryption key. The 'csp_auth_*' fields are always used for auth > keys and settings and 'csp_cipher_*' for cipher. (Compression > algorithms are stored in csp_cipher_alg.) Good point as it was a limiting factor regarding IPsec performance. > > - 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 hardware when creating a new session, you > will no longer get a session using accelerated software. > > Once a driver is chosen, 'crypto_newsession' is invoked as before. Is there an interest to have a software driver and then an accelerated=20 software ? Another approach would be to have a software driver with runtime=20 detection of accelerated algorithms. For example, base SHA1, SSE3 version, VIA SHA1, intel SHA1 instruction It has the advantage to: - allow all combination of software / accelerated software - single driver code (session db, =E2=80=A6) - avoid duplicate driver for software things Regarding the session db every driver has done its own implementation=20 with various performance issue in the past. Do you also plan to refactor the session db ? Regards, Fabien