Open Crypto Framework Changes: Round 1

[Fabien Thomas]

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 
> 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
>
> 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 
software ?
Another approach would be to have a software driver with runtime 
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, …)
- avoid duplicate driver for software things

Regarding the session db every driver has done its own implementation 
with various performance issue in the past.
Do you also plan to refactor the session db ?

Regards,
Fabien