Re: crypto API and IBM z990 hardware support

[James Morris <jmorris@intercode.com.au>]

On Wed, 2 Jul 2003, Thomas Spatzier wrote:

> I agree on having arch-specific implementations in crypto/arch directories.
> However, I've got some problems with having this kind of 'static' aliasing
> in modules.conf. In my case I do not know beforehand, whether a specific
> crypto instruction is enabled. I query some processor status flags during
> runime. If the check fails, I'd like to switch back to the original
> software implementation.

I did say it was the simple solution :-)

> I read in your autoconf.c file that a more sophisticated version of
> crypto_alg_autoload is planned. I would suggest first trying to load the
> arch-specific aes_z990.ko in crypto_alg_autoload. In my init_module
> function i could query the processor. If init_module for my implementation
> fails -> request_module fails -> load the standard module aes.ko.
> Something similar to this:
> 
> #ifndef CRYPTO_ARCH      //defined in arch makefile as "_z990"
> #define CRYPTO_ARCH ""
> #endif
> 
> void crypto_alg_autoload(const char *name)
> {
>       if (request_module("%s%s", name, CRYPTO_ARCH) != 0){
>             request_module("%s", name);
>       }
> }


I'd like to avoid these kind of macros, and make it a general case 
solution (e.g. which can be used for various hardware implementations).

One possibility would be to allow registration with an alias list in
crypto API with attributes indicating whether the module is hardware,
arch-specific etc.

So, during init, the s390 arch could register an alias like:

  name .= "aes_z990"
  algorithm .= "aes"
  attributes .= CRYPTO_ATTR_ARCH|CRYPTO_ATTR_HW

Then, when a caller specifies "aes", crypto_alg_autoload() would first
check the alias list, giving preference to CRYPTO_ALG_ARCH by default.  
In this case, it would find aes_z990 and try and load it.  If this fails,
it continues along the alias list then ultimately falls back to the
current behavior.

This would allow subsystems and hardware drivers to dynamically provide 
information to the API.  Callers of crypto_alloc_tfm() could then pass 
flags specifying preferences for algorithm implementations e.g. generic 
sw, arch sw, arch hw, misc hw.

This would also need to take into account modprobe.conf configuration and 
compiled in modules.



- James
-- 
James Morris
<jmorris@intercode.com.au>