Skip site navigation (1)Skip section navigation (2)
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>