kernel.git/drivers/s390/crypto/zcrypt_ep11misc.h, branch master

s390/pkey: Provide and pass xflags within pkey and zcrypt layers

2025-04-30T09:34:03Z

Provide and pass the xflag parameter from pkey ioctls through the pkey handler and further down to the implementations (CCA, EP11, PCKMO and UV). So all the code is now prepared and ready to support xflags ("execution flag"). The pkey layer supports the xflag PKEY_XFLAG_NOMEMALLOC: If this flag is given in the xflags parameter, the pkey implementation is not allowed to allocate memory but instead should fall back to use preallocated memory or simple fail with -ENOMEM. This flag is for protected key derive within a cipher or similar which must not allocate memory which would cause io operations - see also the CRYPTO_ALG_ALLOCATES_MEMORY flag in crypto.h. Within the pkey handlers this flag is then to be translated to appropriate zcrypt xflags before any zcrypt related functions are called. So the PKEY_XFLAG_NOMEMALLOC translates to ZCRYPT_XFLAG_NOMEMALLOC - If this flag is set, no memory allocations which may trigger any IO operations are done. The pkey in-kernel pkey API still does not provide this xflag param. That's intended to come with a separate patch which enables this functionality. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-25-freude@linux.ibm.com Signed-off-by: Heiko Carstens

s390/zcrypt: Rework ep11 misc functions to use cprb mempool

2025-04-30T09:34:02Z

There are two places in the ep11 misc code where a short term memory buffer is needed. Rework this code to use the cprb mempool to satisfy this ephemeral memory requirements. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-19-freude@linux.ibm.com Signed-off-by: Heiko Carstens

s390/zcrypt: Rework ep11 findcard() implementation and callers

2025-04-30T09:34:02Z

Rework the memory usage of the ep11 findcard() implementation: - findcard does not allocate memory for the list of apqns any more. - the callers are now responsible to provide an array of apqns to store the matching apqns into. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-15-freude@linux.ibm.com Signed-off-by: Heiko Carstens

s390/zcrypt: Remove CCA and EP11 card and domain info caches

2025-04-30T09:34:01Z

Remove the caching of the CCA and EP11 card and domain info. In nearly all places where the card or domain info is fetched the verify param was enabled and thus the cache was bypassed. The only real place where info from the cache was used was in the sysfs pseudo files in cases where the card/queue was switched to "offline". All other callers insisted on getting fresh info and thus a communication to the card was enforced. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-13-freude@linux.ibm.com Signed-off-by: Heiko Carstens

s390/zcrypt: Introduce cprb mempool for ep11 misc functions

2025-04-30T09:34:01Z

Introduce a cprb mempool for the zcrypt ep11 misc functions (zcrypt_ep11misc.*) do some preparation rework to support a do-not-allocate path through some zcrypt ep11 misc functions. The mempool is controlled by the zcrypt module parameter "mempool_threshold" which shall control the minimal amount of memory items for CCA and EP11. The mempool shall support "mempool_threshold" requests/replies in parallel which means for EP11 to hold a send and receive buffer memory per request. Each of this cprb space items is limited to 8 KB. So by default the mempool consumes 5 * 2 * 8KB = 80KB If the mempool is depleted upon one ep11 misc functions is called with the ZCRYPT_XFLAG_NOMEMALLOC xflag set, the function will fail with -ENOMEM and the caller is responsible for taking further actions. This is only part of an rework to support a new xflag ZCRYPT_XFLAG_NOMEMALLOC but not yet complete. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-8-freude@linux.ibm.com Signed-off-by: Heiko Carstens

s390/pkey: Rework and split PKEY kernel module code

2024-08-29T20:56:33Z

This is a huge rework of all the pkey kernel module code. The goal is to split the code into individual parts with a dedicated calling interface: - move all the sysfs related code into pkey_sysfs.c - all the CCA related code goes to pkey_cca.c - the EP11 stuff has been moved to pkey_ep11.c - the PCKMO related code is now in pkey_pckmo.c The CCA, EP11 and PCKMO code may be seen as "handlers" with a similar calling interface. The new header file pkey_base.h declares this calling interface. The remaining code in pkey_api.c handles the ioctl, the pkey module things and the "handler" independent code on top of the calling interface invoking the handlers. This regrouping of the code will be the base for a real pkey kernel module split into a pkey base module which acts as a dispatcher and handler modules providing their service. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik

s390/zcrypt_ep11misc: support API ordinal 6 with empty pin-blob

2023-08-18T13:07:57Z

Secure execution guest environments require an empty pinblob in all key generation and unwrap requests. Empty pinblobs are only available in EP11 API ordinal 6 or higher. Add an empty pinblob to key generation and unwrap requests, if the AP secure binding facility is available. In all other cases, stay with the empty pin tag (no pinblob) and the current API ordinals. The EP11 API ordinal also needs to be considered when the pkey module tries to figure out the list of eligible cards for key operations with protected keys in secure execution environment. These changes are transparent to userspace but required for running an secure execution guest with handling key generate and key derive (e.g. secure key to protected key) correct. Especially using EP11 secure keys with the kernel dm-crypt layer requires this patch. Co-developed-by: Harald Freudenberger Signed-off-by: Harald Freudenberger Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_KBLOB2PROTK[23]

2023-08-17T13:18:53Z

Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced a new PKEY_TYPE_EP11_AES type for the PKEY_KBLOB2PROTK2 and a new IOCTL, PKEY_KBLOB2PROTK3, which both allows userspace to convert opaque securekey blobs of this type into protectedkey blobs. Unfortunately, all PKEY_KBLOB2PROTK2 and PKEY_KBLOB2PROTK3 IOCTL requests with this keyblobs of this type return with an error (-EINVAL). Fix PKEY_TYPE_EP11_AES handling in PKEY_KBLOB2PROTK2 and PKEY_KBLOB2PROTK3 IOCTLs, so that userspace can convert PKEY_TYPE_EP11_AES keyblobs into protectedkey blobs. Add a helper function to decode the start and size of the internal header as well as start and size of the keyblob payload of an existing keyblob. Also validate the length of header and keyblob, as well as the keyblob magic. Introduce another helper function, which handles a raw key wrapping request and do the keyblob decoding in the calling function. Remove all other header-related calculations. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_CLR2SECK2 IOCTL

2023-08-17T13:18:53Z

Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced PKEY_TYPE_EP11_AES for the PKEY_CLR2SECK2 IOCTL to convert an AES clearkey into a securekey of this type. Unfortunately, all PKEY_CLR2SECK2 IOCTL requests with type PKEY_TYPE_EP11_AES return with an error (-EINVAL). Fix the handling for PKEY_TYPE_EP11_AES in PKEY_CLR2SECK2 IOCTL, so that userspace can convert clearkey blobs into PKEY_TYPE_EP11_AES securekey blobs. Cc: stable@vger.kernel.org # v5.10+ Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens

s390/pkey: fix PKEY_TYPE_EP11_AES handling in PKEY_GENSECK2 IOCTL

2023-08-17T13:18:53Z

Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced PKEY_TYPE_EP11_AES for the PKEY_GENSECK2 IOCTL, to enable userspace to generate securekey blobs of this type. Unfortunately, all PKEY_GENSECK2 IOCTL requests for PKEY_TYPE_EP11_AES return with an error (-EINVAL). Fix the handling for PKEY_TYPE_EP11_AES in PKEY_GENSECK2 IOCTL, so that userspace can generate securekey blobs of this type. The start of the header and the keyblob, as well as the length need special handling, depending on the internal keyversion. Add a helper function that splits an uninitialized buffer into start and size of the header as well as start and size of the payload, depending on the requested keyversion. Do the header-related calculations and the raw genkey request handling in separate functions. Use the raw genkey request function for internal purposes. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler Reviewed-by: Ingo Franzki Signed-off-by: Heiko Carstens