Open Crypto Framework Changes: Round 1

[John Baldwin]

On 8/5/19 3:19 AM, Fabien Thomas wrote:
>> - 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

I'm not sure of the best approach.  I do think it can be a feature that,
for example, aesni.ko is a separate driver that can be unloaded if it had
a bug (or if there was some future CPU vuln, etc.).  My leaning is probably
to use an approach where the existing accelerated software drivers would
use the existing software code to implementing missing ETA modes as those
are the only ones missing.

> 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 ?

Conrad already fixed this.  He changed sessions to be opaque pointers
with driver-specific allocated data similar to device_get_softc which
removed all the driver-side version of this entirely.  Driver's now
get a pointer to the session object during the process callback and are
able to obtain their driver-specific session state in constant time via a
single indirection.  This change might only be in 12.0 or later (or
head and later).

-- 
John Baldwin