s390/pkey: Introduce pkey kernel module

This patch introcudes a new kernel module pkey which is providing
protected key handling and management functions. The pkey API is
available w

s390/pkey: Introduce pkey kernel module

This patch introcudes a new kernel module pkey which is providing
protected key handling and management functions. The pkey API is
available within the kernel for other s390 specific code to create
and manage protected keys. Additionally the functions are exported
to user space via IOCTL calls. The implementation makes extensive
use of functions provided by the zcrypt device driver. For
generating protected keys from secure keys there is also a CEX
coprocessor card needed.

Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

s390/zcrypt: add multi domain support

Currently the ap infrastructure only supports one domain at a time.
This feature extends the generic cryptographic device driver to
support mult

s390/zcrypt: add multi domain support

Currently the ap infrastructure only supports one domain at a time.
This feature extends the generic cryptographic device driver to
support multiple cryptographic domains simultaneously.

There are now card and queue devices on the AP bus with independent
card and queue drivers. The new /sys layout is as follows:

/sys/bus/ap
devices
<xx>.<yyyy> -> ../../../devices/ap/card<xx>/<xx>.<yyyy>
...
card<xx> -> ../../../devices/ap/card<xx>
...
drivers
<drv>card
card<xx> -> ../../../../devices/ap/card<xx>
<drv>queue
<xx>.<yyyy> -> ../../../../devices/ap/card<xx>/<xx>.<yyyy>
...

/sys/devices/ap
card<xx>
<xx>.<yyyy>
driver -> ../../../../bus/ap/drivers/<zzz>queue
...
driver -> ../../../bus/ap/drivers/<drv>card
...

The two digit <xx> field is the card number, the four digit <yyyy>
field is the queue number and <drv> is the name of the device driver,
e.g. "cex4".

For compatability /sys/bus/ap/card<xx> for the old layout has to exist,
including the attributes that used to reside there.

With additional contributions from Harald Freudenberger and
Martin Schwidefsky.

Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

s390/zcrypt: Move the ap bus into kernel

Move the ap bus into the kernel and make it general available.
Additionally include the message types and the API layer as a
preparation for

s390/zcrypt: Move the ap bus into kernel

Move the ap bus into the kernel and make it general available.
Additionally include the message types and the API layer as a
preparation for the workload management facility.

Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

s390/zcrypt: Fix initialisation when zcrypt is built-in

ap_bus and zcrypt_api assumed module information to always be present
and initialisation to be done in module loading order (symbo

s390/zcrypt: Fix initialisation when zcrypt is built-in

ap_bus and zcrypt_api assumed module information to always be present
and initialisation to be done in module loading order (symbol
dependencies). These assumptions don't hold if zcrypt is built-in;
THIS_MODULE will be NULL in this case and init call order is linker
order, i.e. Makefile order.

Fix initialisation order by ordering the object files in the Makefile
according to their dependencies, like the module loader would do.

Fix message type registration by using a dedicated "name" field rather
than piggy-backing on the module ("owner") information. There's no
change to the requirement that module name and msgtype name are
identical. The existing name macros are used.

We don't need any special code for dealing with the drivers being
built-in; the generic module support code already does the right
thing.

Test results:
1. CONFIG_MODULES=y, CONFIG_ZCRYPT=y

KVM: boots, no /sys/bus/ap (expected)
LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present

2. CONFIG_MODULES=y, CONFIG_ZCRYPT=m=:

KVM: boots, loading zcrypt_cex4 (and ap) fails (expected)
LPAR with CEX5: boots, loading =zcrypt_cex4= succeeds,
/sys/bus/ap/devices/card*/type present after explicit module
loading

3. CONFIG_MODULES unset, CONFIG_ZCRYPT=y:
KVM: boots, no /sys/bus/ap (expected)
LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present

No further testing (user-space functionality) was done.

Fixes: 3b6245fd303f ("s390/zcrypt: Separate msgtype implementation from card modules.")
Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

s390/zcrypt: remove support for PCICC and PCICA cards

Remove the code for really old crypt cards, PCICC and PCICA.
These cards have been out of service for several years.

Review

s390/zcrypt: remove support for PCICC and PCICA cards

Remove the code for really old crypt cards, PCICC and PCICA.
These cards have been out of service for several years.

Reviewd-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

s390/zcrypt: Add support for CEX4 crypto card

New zcrypt module supports IBM CryptoExpress 4 cards.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin S

s390/zcrypt: Add support for CEX4 crypto card

New zcrypt module supports IBM CryptoExpress 4 cards.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

s390/zcrypt: Separate msgtype implementation from card modules.

Msgtype implementations are now separated from card specific modules
and can be dynamically registered. Existing msgtype i

s390/zcrypt: Separate msgtype implementation from card modules.

Msgtype implementations are now separated from card specific modules
and can be dynamically registered. Existing msgtype implementations
are restructured in modules.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] Remove monolithic build option for zcrypt driver.

Remove the option to build a single module z90crypt that contains
ap bus, request router and card drivers.

Signed-off-by

[S390] Remove monolithic build option for zcrypt driver.

Remove the option to build a single module z90crypt that contains
ap bus, request router and card drivers.

Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] zcrypt driver Makefile, Kconfig and monolithic build.

The Makefile and Kconfig changes should be obvious. The monolithic
build option is there to create an old-style z90crypt modu

[S390] zcrypt driver Makefile, Kconfig and monolithic build.

The Makefile and Kconfig changes should be obvious. The monolithic
build option is there to create an old-style z90crypt module for
backward compatability to older distributions.

Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

[S390] remove old z90crypt driver.

The z90crypt driver has served its term. It is replaced by the shiny
new zcrypt device driver.

Signed-off-by: Martin Schwidefsky <schwidefsky@

[S390] remove old z90crypt driver.

The z90crypt driver has served its term. It is replaced by the shiny
new zcrypt device driver.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

show more ...

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we

Linux-2.6.12-rc2

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!

show more ...