diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/s390/crypto/crypto-API.txt | 83 | ||||
-rw-r--r-- | Documentation/s390/zfcpdump.txt | 87 |
2 files changed, 87 insertions, 83 deletions
diff --git a/Documentation/s390/crypto/crypto-API.txt b/Documentation/s390/crypto/crypto-API.txt deleted file mode 100644 index 71ae6ca9f2c2..000000000000 --- a/Documentation/s390/crypto/crypto-API.txt +++ /dev/null | |||
@@ -1,83 +0,0 @@ | |||
1 | crypto-API support for z990 Message Security Assist (MSA) instructions | ||
2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
3 | |||
4 | AUTHOR: Thomas Spatzier (tspat@de.ibm.com) | ||
5 | |||
6 | |||
7 | 1. Introduction crypto-API | ||
8 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
9 | See Documentation/crypto/api-intro.txt for an introduction/description of the | ||
10 | kernel crypto API. | ||
11 | According to api-intro.txt support for z990 crypto instructions has been added | ||
12 | in the algorithm api layer of the crypto API. Several files containing z990 | ||
13 | optimized implementations of crypto algorithms are placed in the | ||
14 | arch/s390/crypto directory. | ||
15 | |||
16 | |||
17 | 2. Probing for availability of MSA | ||
18 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
19 | It should be possible to use Kernels with the z990 crypto implementations both | ||
20 | on machines with MSA available and on those without MSA (pre z990 or z990 | ||
21 | without MSA). Therefore a simple probing mechanism has been implemented: | ||
22 | In the init function of each crypto module the availability of MSA and of the | ||
23 | respective crypto algorithm in particular will be tested. If the algorithm is | ||
24 | available the module will load and register its algorithm with the crypto API. | ||
25 | |||
26 | If the respective crypto algorithm is not available, the init function will | ||
27 | return -ENOSYS. In that case a fallback to the standard software implementation | ||
28 | of the crypto algorithm must be taken ( -> the standard crypto modules are | ||
29 | also built when compiling the kernel). | ||
30 | |||
31 | |||
32 | 3. Ensuring z990 crypto module preference | ||
33 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
34 | If z990 crypto instructions are available the optimized modules should be | ||
35 | preferred instead of standard modules. | ||
36 | |||
37 | 3.1. compiled-in modules | ||
38 | ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
39 | For compiled-in modules it has to be ensured that the z990 modules are linked | ||
40 | before the standard crypto modules. Then, on system startup the init functions | ||
41 | of z990 crypto modules will be called first and query for availability of z990 | ||
42 | crypto instructions. If instruction is available, the z990 module will register | ||
43 | its crypto algorithm implementation -> the load of the standard module will fail | ||
44 | since the algorithm is already registered. | ||
45 | If z990 crypto instruction is not available the load of the z990 module will | ||
46 | fail -> the standard module will load and register its algorithm. | ||
47 | |||
48 | 3.2. dynamic modules | ||
49 | ~~~~~~~~~~~~~~~~~~~~ | ||
50 | A system administrator has to take care of giving preference to z990 crypto | ||
51 | modules. If MSA is available appropriate lines have to be added to | ||
52 | /etc/modprobe.conf. | ||
53 | |||
54 | Example: z990 crypto instruction for SHA1 algorithm is available | ||
55 | |||
56 | add the following line to /etc/modprobe.conf (assuming the | ||
57 | z990 crypto modules for SHA1 is called sha1_z990): | ||
58 | |||
59 | alias sha1 sha1_z990 | ||
60 | |||
61 | -> when the sha1 algorithm is requested through the crypto API | ||
62 | (which has a module autoloader) the z990 module will be loaded. | ||
63 | |||
64 | TBD: a userspace module probing mechanism | ||
65 | something like 'probe sha1 sha1_z990 sha1' in modprobe.conf | ||
66 | -> try module sha1_z990, if it fails to load standard module sha1 | ||
67 | the 'probe' statement is currently not supported in modprobe.conf | ||
68 | |||
69 | |||
70 | 4. Currently implemented z990 crypto algorithms | ||
71 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
72 | The following crypto algorithms with z990 MSA support are currently implemented. | ||
73 | The name of each algorithm under which it is registered in crypto API and the | ||
74 | name of the respective module is given in square brackets. | ||
75 | |||
76 | - SHA1 Digest Algorithm [sha1 -> sha1_z990] | ||
77 | - DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990] | ||
78 | - Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990] | ||
79 | - Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990] | ||
80 | |||
81 | In order to load, for example, the sha1_z990 module when the sha1 algorithm is | ||
82 | requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf. | ||
83 | |||
diff --git a/Documentation/s390/zfcpdump.txt b/Documentation/s390/zfcpdump.txt new file mode 100644 index 000000000000..cf45d27c4608 --- /dev/null +++ b/Documentation/s390/zfcpdump.txt | |||
@@ -0,0 +1,87 @@ | |||
1 | s390 SCSI dump tool (zfcpdump) | ||
2 | |||
3 | System z machines (z900 or higher) provide hardware support for creating system | ||
4 | dumps on SCSI disks. The dump process is initiated by booting a dump tool, which | ||
5 | has to create a dump of the current (probably crashed) Linux image. In order to | ||
6 | not overwrite memory of the crashed Linux with data of the dump tool, the | ||
7 | hardware saves some memory plus the register sets of the boot cpu before the | ||
8 | dump tool is loaded. There exists an SCLP hardware interface to obtain the saved | ||
9 | memory afterwards. Currently 32 MB are saved. | ||
10 | |||
11 | This zfcpdump implementation consists of a Linux dump kernel together with | ||
12 | a userspace dump tool, which are loaded together into the saved memory region | ||
13 | below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in | ||
14 | the s390-tools package) to make the device bootable. The operator of a Linux | ||
15 | system can then trigger a SCSI dump by booting the SCSI disk, where zfcpdump | ||
16 | resides on. | ||
17 | |||
18 | The kernel part of zfcpdump is implemented as a debugfs file under "zcore/mem", | ||
19 | which exports memory and registers of the crashed Linux in an s390 | ||
20 | standalone dump format. It can be used in the same way as e.g. /dev/mem. The | ||
21 | dump format defines a 4K header followed by plain uncompressed memory. The | ||
22 | register sets are stored in the prefix pages of the respective cpus. To build a | ||
23 | dump enabled kernel with the zcore driver, the kernel config option | ||
24 | CONFIG_ZFCPDUMP has to be set. When reading from "zcore/mem", the part of | ||
25 | memory, which has been saved by hardware is read by the driver via the SCLP | ||
26 | hardware interface. The second part is just copied from the non overwritten real | ||
27 | memory. | ||
28 | |||
29 | The userspace application of zfcpdump can reside e.g. in an intitramfs or an | ||
30 | initrd. It reads from zcore/mem and writes the system dump to a file on a | ||
31 | SCSI disk. | ||
32 | |||
33 | To build a zfcpdump kernel use the following settings in your kernel | ||
34 | configuration: | ||
35 | * CONFIG_ZFCPDUMP=y | ||
36 | * Enable ZFCP driver | ||
37 | * Enable SCSI driver | ||
38 | * Enable ext2 and ext3 filesystems | ||
39 | * Disable as many features as possible to keep the kernel small. | ||
40 | E.g. network support is not needed at all. | ||
41 | |||
42 | To use the zfcpdump userspace application in an initramfs you have to do the | ||
43 | following: | ||
44 | |||
45 | * Copy the zfcpdump executable somewhere into your Linux tree. | ||
46 | E.g. to "arch/s390/boot/zfcpdump. If you do not want to include | ||
47 | shared libraries, compile the tool with the "-static" gcc option. | ||
48 | * If you want to include e2fsck, add it to your source tree, too. The zfcpdump | ||
49 | application attempts to start /sbin/e2fsck from the ramdisk. | ||
50 | * Use an initramfs config file like the following: | ||
51 | |||
52 | dir /dev 755 0 0 | ||
53 | nod /dev/console 644 0 0 c 5 1 | ||
54 | nod /dev/null 644 0 0 c 1 3 | ||
55 | nod /dev/sda1 644 0 0 b 8 1 | ||
56 | nod /dev/sda2 644 0 0 b 8 2 | ||
57 | nod /dev/sda3 644 0 0 b 8 3 | ||
58 | nod /dev/sda4 644 0 0 b 8 4 | ||
59 | nod /dev/sda5 644 0 0 b 8 5 | ||
60 | nod /dev/sda6 644 0 0 b 8 6 | ||
61 | nod /dev/sda7 644 0 0 b 8 7 | ||
62 | nod /dev/sda8 644 0 0 b 8 8 | ||
63 | nod /dev/sda9 644 0 0 b 8 9 | ||
64 | nod /dev/sda10 644 0 0 b 8 10 | ||
65 | nod /dev/sda11 644 0 0 b 8 11 | ||
66 | nod /dev/sda12 644 0 0 b 8 12 | ||
67 | nod /dev/sda13 644 0 0 b 8 13 | ||
68 | nod /dev/sda14 644 0 0 b 8 14 | ||
69 | nod /dev/sda15 644 0 0 b 8 15 | ||
70 | file /init arch/s390/boot/zfcpdump 755 0 0 | ||
71 | file /sbin/e2fsck arch/s390/boot/e2fsck 755 0 0 | ||
72 | dir /proc 755 0 0 | ||
73 | dir /sys 755 0 0 | ||
74 | dir /mnt 755 0 0 | ||
75 | dir /sbin 755 0 0 | ||
76 | |||
77 | * Issue "make image" to build the zfcpdump image with initramfs. | ||
78 | |||
79 | In a Linux distribution the zfcpdump enabled kernel image must be copied to | ||
80 | /usr/share/zfcpdump/zfcpdump.image, where the s390 zipl tool is looking for the | ||
81 | dump kernel when preparing a SCSI dump disk. | ||
82 | |||
83 | If you use a ramdisk copy it to "/usr/share/zfcpdump/zfcpdump.rd". | ||
84 | |||
85 | For more information on how to use zfcpdump refer to the s390 'Using the Dump | ||
86 | Tools book', which is available from | ||
87 | http://www.ibm.com/developerworks/linux/linux390. | ||