Merge branch 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6

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.

s390 SCSI dump tool (zfcpdump)

System z machines (z900 or higher) provide hardware support for creating system

dumps on SCSI disks. The dump process is initiated by booting a dump tool, which

has to create a dump of the current (probably crashed) Linux image. In order to

not overwrite memory of the crashed Linux with data of the dump tool, the

hardware saves some memory plus the register sets of the boot cpu before the

dump tool is loaded. There exists an SCLP hardware interface to obtain the saved

memory afterwards. Currently 32 MB are saved.

This zfcpdump implementation consists of a Linux dump kernel together with

a userspace dump tool, which are loaded together into the saved memory region

below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in

the s390-tools package) to make the device bootable. The operator of a Linux

system can then trigger a SCSI dump by booting the SCSI disk, where zfcpdump

resides on.

The kernel part of zfcpdump is implemented as a debugfs file under "zcore/mem",

which exports memory and registers of the crashed Linux in an s390

standalone dump format. It can be used in the same way as e.g. /dev/mem. The

dump format defines a 4K header followed by plain uncompressed memory. The

register sets are stored in the prefix pages of the respective cpus. To build a

dump enabled kernel with the zcore driver, the kernel config option

CONFIG_ZFCPDUMP has to be set. When reading from "zcore/mem", the part of

memory, which has been saved by hardware is read by the driver via the SCLP

hardware interface. The second part is just copied from the non overwritten real

memory.

The userspace application of zfcpdump can reside e.g. in an intitramfs or an

initrd. It reads from zcore/mem and writes the system dump to a file on a

SCSI disk.

To build a zfcpdump kernel use the following settings in your kernel

configuration:

 * CONFIG_ZFCPDUMP=y

 * Enable ZFCP driver

 * Enable SCSI driver

 * Enable ext2 and ext3 filesystems

 * Disable as many features as possible to keep the kernel small.

   E.g. network support is not needed at all.

To use the zfcpdump userspace application in an initramfs you have to do the

following:

 * Copy the zfcpdump executable somewhere into your Linux tree.

   E.g. to "arch/s390/boot/zfcpdump. If you do not want to include

   shared libraries, compile the tool with the "-static" gcc option.

 * If you want to include e2fsck, add it to your source tree, too. The zfcpdump

   application attempts to start /sbin/e2fsck from the ramdisk.

 * Use an initramfs config file like the following:

   dir /dev 755 0 0

   nod /dev/console 644 0 0 c 5 1

   nod /dev/null 644 0 0 c 1 3

   nod /dev/sda1 644 0 0 b 8 1

   nod /dev/sda2 644 0 0 b 8 2

   nod /dev/sda3 644 0 0 b 8 3

   nod /dev/sda4 644 0 0 b 8 4

   nod /dev/sda5 644 0 0 b 8 5

   nod /dev/sda6 644 0 0 b 8 6

   nod /dev/sda7 644 0 0 b 8 7

   nod /dev/sda8 644 0 0 b 8 8

   nod /dev/sda9 644 0 0 b 8 9

   nod /dev/sda10 644 0 0 b 8 10

   nod /dev/sda11 644 0 0 b 8 11

   nod /dev/sda12 644 0 0 b 8 12

   nod /dev/sda13 644 0 0 b 8 13

   nod /dev/sda14 644 0 0 b 8 14

   nod /dev/sda15 644 0 0 b 8 15

   file /init arch/s390/boot/zfcpdump 755 0 0

   file /sbin/e2fsck arch/s390/boot/e2fsck 755 0 0

   dir /proc 755 0 0

   dir /sys 755 0 0

   dir /mnt 755 0 0

   dir /sbin 755 0 0

 * Issue "make image" to build the zfcpdump image with initramfs.

In a Linux distribution the zfcpdump enabled kernel image must be copied to

/usr/share/zfcpdump/zfcpdump.image, where the s390 zipl tool is looking for the

dump kernel when preparing a SCSI dump disk.

If you use a ramdisk copy it to "/usr/share/zfcpdump/zfcpdump.rd".

For more information on how to use zfcpdump refer to the s390 'Using the Dump

Tools book', which is available from

http://www.ibm.com/developerworks/linux/linux390.

config GENERIC_TIME

	def_bool y

config GENERIC_BUG

	bool

	depends on BUG

	default y

config NO_IOMEM

	def_bool y

	  current kernel, and to start another kernel.  It is like a reboot

	  but is independent of hardware/microcode support.

config ZFCPDUMP

	tristate "zfcpdump support"

	select SMP

	default n

	help

	  Select this option if you want to build an zfcpdump enabled kernel.

	  Refer to "Documentation/s390/zfcpdump.txt" for more details on this.

endmenu

source "net/Kconfig"

ifeq ($(call cc-option-yn,-mstack-size=8192 -mstack-guard=128),y)

cflags-$(CONFIG_CHECK_STACK) += -mstack-size=$(STACK_SIZE)

ifneq ($(call cc-option-yn,-mstack-size=8192),y)

cflags-$(CONFIG_CHECK_STACK) += -mstack-guard=$(CONFIG_STACK_GUARD)

endif

endif

ifeq ($(call cc-option-yn,-mwarn-dynamicstack),y)

cflags-$(CONFIG_WARN_STACK) += -mwarn-dynamicstack

image: vmlinux

	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@

zfcpdump:

	$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@

archclean:

	$(Q)$(MAKE) $(clean)=$(boot)

EXPORT_SYMBOL_GPL(appldata_unregister_ops);

EXPORT_SYMBOL_GPL(appldata_diag);

#ifdef MODULE

/*

 * Kernel symbols needed by appldata_mem and appldata_os modules.

 * However, if this file is compiled as a module (for testing only), these

 * symbols are not exported. In this case, we define them locally and export

 * those.

 */

void si_swapinfo(struct sysinfo *val)

{

	val->freeswap = -1ul;

	val->totalswap = -1ul;

}

unsigned long avenrun[3] = {-1 - FIXED_1/200, -1 - FIXED_1/200,

				-1 - FIXED_1/200};

int nr_threads = -1;

void get_full_page_state(struct page_state *ps)

{

	memset(ps, -1, sizeof(struct page_state));

}

unsigned long nr_running(void)

{

	return -1;

}

unsigned long nr_iowait(void)

{

	return -1;

}

/*unsigned long nr_context_switches(void)

{

	return -1;

}*/

#endif /* MODULE */

EXPORT_SYMBOL_GPL(si_swapinfo);

EXPORT_SYMBOL_GPL(nr_threads);

EXPORT_SYMBOL_GPL(nr_running);

EXPORT_SYMBOL_GPL(nr_iowait);

//EXPORT_SYMBOL_GPL(nr_context_switches);