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

s390: Remove KMSG_COMPONENT macro

2025-11-24T10:45:21Z

The KMSG_COMPONENT macro is a leftover of the s390 specific "kernel message catalog" which never made it upstream. Remove the macro in order to get rid of a pointless indirection. Replace all users with the string it defines. In almost all cases this leads to a simple replacement like this: - #define KMSG_COMPONENT "appldata" - #define pr_fmt(fmt) KMSG_COMPONENT ": " fmt + #define pr_fmt(fmt) "appldata: " fmt Except for some special cases this is just mechanical/scripted work. Acked-by: Thomas Richter Signed-off-by: Heiko Carstens

s390/pkey: Forward keygenflags to ep11_unwrapkey

2025-08-28T14:52:54Z

The pkey ioctl PKEY_CLR2SECK2 describes in the pkey.h header file the parameter 'keygenflags' which is forwarded to the handler functions which actually deal with the clear key to secure key operation. The ep11 handler module function ep11_clr2keyblob() function receives this parameter but does not forward it to the underlying function ep11_unwrapkey() on invocation. So in the end the user of this ioctl could not forward additional key generation flags to the ep11 implementation and thus was unable to modify the key generation process in any way. So now call ep11_unwrapkey() with the real keygenflags instead of 0 and thus the user of this ioctl can for example via keygenflags provide valid combinations of XCP_BLOB_* flags. Suggested-by: Ingo Franzki Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Franzki Signed-off-by: Alexander Gordeev

s390/drivers: Explicitly include

2025-06-17T16:18:02Z

Explicitly include in files which contain an EXPORT_SYMBOL(). See commit a934a57a42f6 ("scripts/misc-check: check missing #include when W=1") for more details. Acked-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev

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: Locate ep11_domain_query_info onto the stack instead of kmalloc

2025-04-30T09:34:02Z

Locate the relative small struct ep11_domain_query_info variable onto the stack instead of kmalloc()/kfree(). Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-18-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 pre-allocated device status array for ep11 misc

2025-04-30T09:34:01Z

Introduce a pre-allocated device status array memory together with a mutex controlling the occupation to be used by the findcard() function. Limit the device status array to max 128 cards and max 128 domains to reduce the size of this pre-allocated memory to 64 KB. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-11-freude@linux.ibm.com Signed-off-by: Heiko Carstens

s390/zcrypt: Rework zcrypt function zcrypt_device_status_mask_ext

2025-04-30T09:34:01Z

Rework the existing function zcrypt_device_status_mask_ext(): Add two new parameters to provide upper limits for cards and queues. The existing implementation needed an array of 256 * 256 * 4 = 256 KB which is really huge. The reworked function is more flexible in the sense that the caller can decide the upper limit for cards and domains to be stored into the status array. So for example a caller may decide to only query for cards 0...127 and queues 0...127 and thus only an array of size 128 * 128 * 4 = 64 KB is needed. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Link: https://lore.kernel.org/r/20250424133619.16495-9-freude@linux.ibm.com Signed-off-by: Heiko Carstens