Re: crypto API and IBM z990 hardware support

From: James Morris (
Date: Wed Jul 02 2003 - 04:35:16 EST

On Wed, 2 Jul 2003, Thomas Spatzier wrote:

> Hello James,
> I'm currently looking at the crypto API and considering adding support for
> new hardware instructions implemented in the IBM z990 architecture. Since I
> found your name in most of the files I find it appropriate to ask for your
> opinion on how to integrate the new code (from a design point of view).
> z990 provides hardware support for AES, DES and SHA. The problem is, that
> the respective instructions might not be implemented on all z990 systems
> (export restrictions etc). Hence, a check must be run to test whether the
> instruction set is present, and if not, a fall-back to the current software
> implementation must be taken.

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

> I basically have two solutions in mind: (1)
> to integrate the new code into the current crypto files; add some #ifdef s
> to prevent the code from being compiled when building a non-z990 kernel;
> add some ifs for runtime check.

No, the core crypto code should not be altered with #ifdefs to handle some
arch specific issue.

> (2) include the new code into an arch/s390/crypto directory. The
> advantage of (1) is that there are no seperate crypto directories, the
> code doesn't drift apart. Furthermore, it's probably the best solution
> with respect to the kernel module loader. On the other hand, the
> hardware support is very arch-specific, which would fit in option (2).
> (2) however has the disadvantage that there are multiple crypto modules;
> the user has to select one to load -> must have different names for one
> algorithm. What is your opinion on this subject?

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:


where on i386, aes.s would be built into aes.o and aes.c would not be

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.

- 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:15 EST