Tests showed that the keygenflags parameter is not handled
correctly within the zcrypt ccamisc generate cca cipher key
code. A similar code is used with cca cipher key value import
and there the flags are handled correctly. For unknown reason
these lines have not been updated for the generate function
and so this patch now introduces these two lines of code.
This affects only pkey with the use of CCA cipher keys and
the use of additional key generate flags.
Fixes: 4bc123b18c ("s390/zcrypt: Add low level functions for CCA AES cipher keys")
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Introduce new ioctls and structs to be used with these new ioctls
which are able to handle CCA AES secure keys and CCA AES cipher keys:
PKEY_GENSECK2: Generate secure key, version 2.
Generate either a CCA AES secure key or a CCA AES cipher key.
PKEY_CLR2SECK2: Generate secure key from clear key value, version 2.
Construct a CCA AES secure key or CCA AES cipher key from a given
clear key value.
PKEY_VERIFYKEY2: Verify the given secure key, version 2.
Check for correct key type. If cardnr and domain are given, also
check if this apqn is able to handle this type of key. If cardnr and
domain are 0xFFFF, on return these values are filled with an apqn
able to handle this key. The function also checks for the master key
verification patterns of the key matching to the current or
alternate mkvp of the apqn. CCA AES cipher keys are also checked
for CPACF export allowed (CPRTCPAC flag). Currently CCA AES secure
keys and CCA AES cipher keys are supported (may get extended in the
future).
PKEY_KBLOB2PROTK2: Transform a key blob (of any type) into
a protected key, version 2. Difference to version 1 is only that
this new ioctl has additional parameters to provide a list of
apqns to be used for the transformation.
PKEY_APQNS4K: Generate a list of APQNs based on the key blob given.
Is able to find out which type of secure key is given (CCA AES
secure key or CCA AES cipher key) and tries to find all matching
crypto cards based on the MKVP and maybe other criterias (like CCA
AES cipher keys need a CEX6C or higher). The list of APQNs is
further filtered by the key's mkvp which needs to match to either
the current mkvp or the alternate mkvp (which is the old mkvp on CCA
adapters) of the apqns. The flags argument may be used to limit the
matching apqns. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the
current mkvp of each apqn is compared. Likewise with the
PKEY_FLAGS_MATCH_ALT_MKVP. If both are given it is assumed to return
apqns where either the current or the alternate mkvp matches. If no
matching APQN is found, the ioctl returns with 0 but the
apqn_entries value is 0.
PKEY_APQNS4KT: Generate a list of APQNs based on the key type given.
Build a list of APQNs based on the given key type and maybe further
restrict the list by given master key verification patterns.
For different key types there may be different ways to match the
master key verification patterns. For CCA keys (CCA data key and CCA
cipher key) the first 8 bytes of cur_mkvp refer to the current mkvp
value of the apqn and the first 8 bytes of the alt_mkvp refer to the
old mkvp. The flags argument controls if the apqns current and/or
alternate mkvp should match. If the PKEY_FLAGS_MATCH_CUR_MKVP is
given, only the current mkvp of each apqn is compared. Likewise with
the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given, it is assumed to
return apqns where either the current or the alternate mkvp
matches. If no matching APQN is found, the ioctl returns with 0 but
the apqn_entries value is 0.
These new ioctls are now prepared for another new type of secure key
blob which may come in the future. They all use a pointer to the key
blob and a key blob length information instead of some hardcoded byte
array. They all use the new enums pkey_key_type, pkey_key_size and
pkey_key_info for getting/setting key type, key size and additional
info about the key. All but the PKEY_VERIFY2 ioctl now work based on a
list of apqns. This list is walked through trying to perform the
operation on exactly this apqn without any further checking (like card
type or online state). If the apqn fails, simple the next one in the
list is tried until success (return 0) or the end of the list is
reached (return -1 with errno ENODEV). All apqns in the list need to
be exact apqns (0xFFFF as any card or domain is not allowed). There
are two new ioctls which can be used to build a list of apqns based on
a key or key type and maybe restricted by match to a current or
alternate master key verifcation pattern.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
This patch adds low level functions, structs and defines to support
CCA AES cipher keys:
- struct cipherkeytoken can be used for an inside view of the CCA AES
cipher key token blob.
- function cca_cipher2protkey() derives an CPACF protected key from an
CCA AES cipher key.
- function cca_gencipherkey() generates an CCA AES cipher key with
random value.
- function cca_findcard2() constructs a list of apqns based on input
constrains like min hardware type, mkvp values.
- cca_check_secaescipherkey() does a check on the given CCA AES cipher
key blob.
- cca_clr2cipherkey() generates an CCA AES cipher key from a given
clear key value.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Rework and extension of the cca_findcard function to be prepared for
other types of secure key blobs. Split the function and extract an
internal function which has no awareness of key blobs any
more. Improve this function and the helper code around to be able to
check for a minimal crypto card hardware level (Background: the newer
AES cipher keys need to match to the master key verification pattern
and need to have a crypto card CEX6 or higher).
No API change, neither for the in-kernel API nor the ioctl interface.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
This patch extends the sysfs interface with two new attributes for the
CEX4, CEX5 and CEX6 crypto cards/queues in coprocessor ('CCA') mode:
/sys/devices/ap/cardxx/serialnr
/sys/devices/ap/cardxx/xx.yyyy/mkvps
The serialnr attribute is card based and shows the 8 character ASCII
serial number string which should unique identify the card.
The mkvps is queue based and displays 3 lines of information about the
new, current and old master key register:
AES NEW: <new_aes_mk_state> <new_aes_mk_mkvp>
AES CUR: <cur_aes_mk_state> <cur_aes_mk_mkvp>
AES OLD: <old_aes_mk_state> <old_aes_mk_mkvp>
with
<new_aes_mk_state>: 'empty' or 'partial' or 'full'
<cur_aes_mk_state>: 'valid' or 'invalid'
<old_aes_mk_state>: 'valid' or 'invalid'
<new_aes_mk_mkvp>, <cur_aes_mk_mkvp>, <old_aes_mk_mkvp>
8 byte hex string with leading 0x
MKVP means Master Key Verification Pattern and is a folded hash over
the key value. Only the states 'full' and 'valid' result in displaying
a useful mkvp, otherwise a mkvp of all bytes zero is shown. If for any
reason the FQ fails and the (cached) information is not available, the
state '-' will be shown with the mkvp value also '-'. The values shown
here are the very same as the cca panel tools displays. As of now only
the AES master keys states and verification patterns are shown. A CCA
APQN also has similar master key registers for DES, RSA and ECC. So
the content of this attribute may get extended.
Reading the sysfs attribute automatically triggers an FQ CPRB to be
sent to the queue as long as the queue is (soft-) online. For the
serialnr attribute the queue with the default domain id is addressed
(if available and valid). This is reasonable as it is assumed that
this sysfs interface is not performance critical and on the other side
a master key change should be visiable as soon as possible. When a
queue is (soft-) offline however, the cached values are displayed. If
no cached values are available, the serial number string will be empty
and the mkvp lines will show state '-' and mkvp value '-'.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
This patch widens the information held for cca crypto apqns.
Currently the current and old master key verification pattern
is used by the existing code. Now the new master key registers
mkvp, the 8 byte serial number and state info about each master
key register is part of the cca info cache.
In a next step this information will be used to provide some
additional attributes in sysfs for each CCA crypto adapter.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Rework of the pkey code. Moved all the cca generic code
away from pkey_api.c into a new file zcrypt_ccamisc.c.
This new file is now part of the zcrypt device driver
and exports a bunch of cca functions to pkey and may
be called from other kernel modules as well.
The pkey ioctl API is unchanged.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Harald Freudenberger