Date: Thu, 21 Nov 2019 11:40:48 -0800 From: John Baldwin <jhb@FreeBSD.org> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: CFT: Open Crypto Framework Changes: Round 1 Message-ID: <921919dd-6291-61af-2dc6-768bcdbd5cff@FreeBSD.org> 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
On 8/2/19 3:46 PM, John Baldwin wrote: > 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 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 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 I have progressed further on this work and would like to merge it into the tree soon. Some changes since the last summary I gave are: - Key lengths are now in bytes instead of bits to match all the other '*len' fields. Key lengths are also only in the session parameters and are fixed for the lifetime of a session. - Various helper functions to reduce code duplication in drivers. - Sessions that use per-op keys (such as GELI) can now be created without having to specify an initial key. - I have converted all drivers and consumers in the tree and verified that they compile, but I have not tested all of them. I have tested the following drivers: - cryptosoft - aesni (AES only) - blake2 - ccr and the following consumers: - cryptodev - IPsec - ktls_ocf I have not tested the following: - ccp - aesni with sha - hifn - kgssapi_krb5 - ubsec - padlock - safe - GELI - armv8_crypto (aarch64) - glxsb (i386) - sec (ppc) - cesa (armv7) - cryptocteon (mips64) - nlmsec (mips64) Help with additional testing would be greatly appreciated. Note that for drivers an easy way to test is to run 'cryptocheck -vaz' before and after. The output from cryptocheck should be identical, and there should be no mismatches. Some of these drivers had some dubious behavior (e.g. trying to carry over IVs across requests within a session), though they may have worked for at least some IPsec use cases before. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?921919dd-6291-61af-2dc6-768bcdbd5cff>