CFT: Open Crypto Framework Changes: Round 1

[John Baldwin]

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