crypto API and IBM z990 hardware support

Right.

Still too complicated imho. The built-in code should not need to know about which modules exist. For example that would prevent autoloading of third-party hardware crypto drivers. In most cases, a first-come-first-serve approach is sufficient and works without changes to the current code. Modules implementing the same algorithm can just set .cra_name to the same value.

For built-in drivers, link order decides which implementation is preferred. Consequently, hardware crypto drivers need to come before software implementations and must not register themselves if the hardware is not found at initcall time.

For the module case, the aes-z990.o module could declare 'MODULE_ALIAS(aes-hw);', the simple patch below makes sure that any aes-hw module is preferred to the software aes module. If there is more than one hardware implementation available for an architecture, either the autoloader can be extended further, or modprobe has to be configured appropriately.

        Arnd <><

===== crypto/autoload.c 1.7 vs edited =====

@@ -21,16 +21,15 @@
  * A far more intelligent version of this is planned.  For now, just
  * try an exact match on the name of the algorithm.
  */
-void crypto_alg_autoload(const char *name)
-{
-       request_module("%s", name);
-}
-
 struct crypto_alg *crypto_alg_mod_lookup(const char *name)
 {
        struct crypto_alg *alg = crypto_alg_lookup(name);
        if (alg == NULL) {
-               crypto_alg_autoload(name);
+               request_module("%s-hw", name);
+               alg = crypto_alg_lookup(name);
+       }
+       if (alg == NULL) {
+               request_module("%s", name);
                alg = crypto_alg_lookup(name);
        }
        return alg;

While this looks like it will work fine for the z990, it is a special case which does not address other requirements for hardware support (some initial requirements are listed at
http://www.intercode.com.au/jamesm/crypto/hardware_notes.txt).

I'm not enthusiastic about adding infrastructure which is really just a hack for some quaint hardware, and probably does not work towards addressing more common hardware requirements.

- James

James Morris
<[email protected]>

Ok, then I guess the module will simply have to declare MODULE_ALIAS("aes") and live in arch/s390/crypto/, which means that the common code is not touched at all, but building both the z990 assembler as well as the C implementation as modules requires editing /etc/modprobe.conf to get the right one.

As soon as you have the new API for crypto cards, we can move to that for autoprobing the CPU features and reliably using the right implementation.

Maybe you can add to your list something like the following items:

Requirements:
- Support for CPU specific optimized algorithms:
- autodetection of CPU features (e.g. Pentium MMX or z990 crypto)
- selection of different implementations. A high priority job probably wants to use the CPU while another job offloads crypto to an asynchronous add-on card.

Hardware Documentation status:
- IBM zSeries cryptographic instructions:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dz9zr002/7.5.25

GPL Driver status:
- IBM PCICC and PCICA cards (incompatible API):
Robert Burroughs <[email protected]>
http://oss.software.ibm.com/developerworks/opensource/linux390/june2003_recommended.shtml
- IBM zSeries cryptographic instructions:
Thomas Spatzier (work in progress)

	Arnd <><

The z990 isn't really crypto hw in the traditional sense, it has special instructions in the CPU so from Linux POV it's more an extremly optimized SW implementation..

And we have to solve this anyway even iof support for external crypto hw is delayed. Think of integrating Jari's x86 assembly aes implementation or similar things.