s390/pkey: add CCA AES cipher key support
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: