Date: Mon, 05 Aug 2019 12:19:13 +0200 From: "Fabien Thomas" <fabien.thomas@stormshield.eu> To: "John Baldwin" <jhb@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: Open Crypto Framework Changes: Round 1 Message-ID: <9E88949D-92D5-40EA-8ACA-B10E56102476@stormshield.eu> In-Reply-To: <c83b6b93-138d-26ca-6edf-4abac4df3d7f@FreeBSD.org> References: <c83b6b93-138d-26ca-6edf-4abac4df3d7f@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9E88949D-92D5-40EA-8ACA-B10E56102476>