blob: 71ae6ca9f2c24ae68f1da9a379a844865ceb6c62 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
crypto-API support for z990 Message Security Assist (MSA) instructions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AUTHOR: Thomas Spatzier (tspat@de.ibm.com)
1. Introduction crypto-API
~~~~~~~~~~~~~~~~~~~~~~~~~~
See Documentation/crypto/api-intro.txt for an introduction/description of the
kernel crypto API.
According to api-intro.txt support for z990 crypto instructions has been added
in the algorithm api layer of the crypto API. Several files containing z990
optimized implementations of crypto algorithms are placed in the
arch/s390/crypto directory.
2. Probing for availability of MSA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It should be possible to use Kernels with the z990 crypto implementations both
on machines with MSA available and on those without MSA (pre z990 or z990
without MSA). Therefore a simple probing mechanism has been implemented:
In the init function of each crypto module the availability of MSA and of the
respective crypto algorithm in particular will be tested. If the algorithm is
available the module will load and register its algorithm with the crypto API.
If the respective crypto algorithm is not available, the init function will
return -ENOSYS. In that case a fallback to the standard software implementation
of the crypto algorithm must be taken ( -> the standard crypto modules are
also built when compiling the kernel).
3. Ensuring z990 crypto module preference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If z990 crypto instructions are available the optimized modules should be
preferred instead of standard modules.
3.1. compiled-in modules
~~~~~~~~~~~~~~~~~~~~~~~~
For compiled-in modules it has to be ensured that the z990 modules are linked
before the standard crypto modules. Then, on system startup the init functions
of z990 crypto modules will be called first and query for availability of z990
crypto instructions. If instruction is available, the z990 module will register
its crypto algorithm implementation -> the load of the standard module will fail
since the algorithm is already registered.
If z990 crypto instruction is not available the load of the z990 module will
fail -> the standard module will load and register its algorithm.
3.2. dynamic modules
~~~~~~~~~~~~~~~~~~~~
A system administrator has to take care of giving preference to z990 crypto
modules. If MSA is available appropriate lines have to be added to
/etc/modprobe.conf.
Example: z990 crypto instruction for SHA1 algorithm is available
add the following line to /etc/modprobe.conf (assuming the
z990 crypto modules for SHA1 is called sha1_z990):
alias sha1 sha1_z990
-> when the sha1 algorithm is requested through the crypto API
(which has a module autoloader) the z990 module will be loaded.
TBD: a userspace module probing mechanism
something like 'probe sha1 sha1_z990 sha1' in modprobe.conf
-> try module sha1_z990, if it fails to load standard module sha1
the 'probe' statement is currently not supported in modprobe.conf
4. Currently implemented z990 crypto algorithms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following crypto algorithms with z990 MSA support are currently implemented.
The name of each algorithm under which it is registered in crypto API and the
name of the respective module is given in square brackets.
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.
|
