Re: crypto API and IBM z990 hardware support

From: Thomas Spatzier (TSPAT@de.ibm.com)
Date: Wed Jul 02 2003 - 07:35:04 EST


> Are there any details available on how all of this is implemented? Are
> these instructions synchronous?

Yes, the instructions are sunchronous.

> The plan is to provide crypto/arch/ subdirectories where arch optimized
> versions of the crypto algorithms are implemented, and built
automatically
> (via configuration defaults) instead of the generic C versions.
>
> So, there might be:
>
> crypto/aes.c
> crypto/arch/i386/aes.s
>
> where on i386, aes.s would be built into aes.o and aes.c would not be
> built.
>
> The simple solution for you might be something like:
>
> crypto/aes.c -> aes.o
> crypto/arch/s390/aes_z990.c -> aes_z990.o
>
> and the administrator of the system could configure modprobe.conf to
alias
> aes to aes_z990 if the latter is supported in hardware.

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 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);
      }
}

Regards,

Thomas Spatzier
--------------------------------------------------
+49-7031-16-1219
TSPAT@de.ibm.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



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