Re: crypto API and IBM z990 hardware support

From: James Morris (
Date: Wed Jul 02 2003 - 11:57:30 EST

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"

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

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:16 EST