From: Harald Freudenberger <freude@linux.ibm.com>
To: dengler@linux.ibm.com, ifranzki@linux.ibm.com,
fcallies@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com,
agordeev@linux.ibm.com, seiden@linux.ibm.com
Cc: linux-s390@vger.kernel.org, herbert@gondor.apana.org.au
Subject: [PATCH v5 00/25] AP bus/zcrypt/pkey/paes no-mem-alloc patches
Date: Tue, 15 Apr 2025 16:24:13 +0200 [thread overview]
Message-ID: <20250415142438.118474-1-freude@linux.ibm.com> (raw)
This series of patches has the goal to open up a do-not-allocate
memory path from the callers of the pkey in-kernel api down to
the crypto cards and back.
The asynch in-kernel cipher implementations (and the s390 PAES
cipher implementations are one of them) may be called in a
context where memory allocations which trigger IO is not acceptable.
So this patch series reworks the AP bus code, the zcrypt layer,
the pkey layer and the pkey handlers to respect this situation
by processing a new parameter xflags (execution hints flags).
There is a flag PKEY_XFLAG_NOMEMALLOC which tells the code to
not allocate memory which may lead to IO operations.
To reach this goal, the actual code changes have been differed.
The zcrypt misc functions which need memory for cprb build
use a pre allocated memory pool for this purpose. The findcard()
functions have one temp memory area preallocated and protected
with a mutex. Some smaller data is not allocated any more but went
to the stack instead. The AP bus also uses a pre-allocated
memory pool for building AP message requests.
Note that the PAES implementation still needs to get reworked
to run the protected key derivation in a real asynchronous way.
However, this rework of AP bus, zcrypt and pkey is the base work
required before reconsidering the PAES implementation.
The patch series starts bottom (AP bus) and goes up the call
chain (PKEY). At any time in the patch stack it should compile.
For easier review I tried to have one logic code change by
each patch and thus keep the patches "small". For the upstream
version I intend to fold them together into only a few commits.
Changelog:
v1: initial version
v2: - Rework on patch 0001 and 0002 based on feedback from Holger.
Also there was one place in zcrypt_msgtype50.c where still
an ap msg buffer was alloacated.
- Rework on patch 0003 - fixed feedback from Holger. Also the
min poolitems is now a module parameter and defaults to 8.
- Rework on patch 0004 - as suggested by Holger the "userspace"
parameter is now included into the ap msg flags.
- Rework on patch 0005 - nr of cca cprbs in the mempool is now
a module parameter.
- Rework on patch 0006 - nr of ep11 cprbs in the mempool is now
a module parameter.
- Rework on patch 0007 - as suggested by Holger instead of
implementing a copy-and-pasted new function
zcrypt_device_status_mask_ext2() use and extend the existing
the existing function to avoid code duplication.
- The rest of the patch series needed adaptions but there is
no functional change compared to v1.
v3: Rework based on feedback from Holger:
- There is now one zcrypt module parameter "mempool_threshold"
controlling the cprb mempools for CCA and EP11. The default
value of 5 shall cover 5 CCA or EP11 requests/replies in parallel.
- The cca and ep11 card and domain info cache is done - anyway
nearly all callers used the verify=1 to enforce the retrieval
of fresh information. So now this info is always freshly fetched
from the card/domain.
- Holger found out that there are some unused functions lurking
around - deleted :-)
- The only thing still missing is no-mem support for the UV
driver. As of now the pkey uv layer refuses to contact the UV
dd in case the NOMEMALLOC flag is given.
- Tested and found no issues.
v4: Still some minor changes:
- The UV patch is now part of this patch series
- With that came a slight rework of the pkey uv handler code.
It is now pre-allocating one struct for use with the UV driver.
- The zcrypt api module parameter mempool_threshold is now
checked and enforced to have at least a value of 1.
- Heiko found some things, for example the mempool_create()
was for some reason checking for PTR_ERR which does not apply to
the used way of creating the mempools - fixed in all patches.
- Heiko also had the question about the artificial limit of
16 APQNs as target addressing for EP11 cprbs. Together with
Holger we found out, that this is not needed at all - so yet
another patch now reworks this code (see patch "s390/zcrypt:
Avoid alloc and copy of ep11 targets if kernelspace cprb").
v5: - new patch for the uv code to support another non-malloc
interface function ("s390/uv: Rename find_secret() to
uv_find_secret() and publish")
- with that a slight rework of the pkey uv handler which is
now able to retrieve uv protected key secrets without malloc.
- new patch for the uv code to remove the old interface function
("s390/uv: Remove uv_get_secret_metadata function").
- Lots of minor reworks triggered by review comments from
Holger.
Harald Freudenberger (25):
s390/ap: Move response_type struct into ap_msg struct
s390/ap/zcrypt: Rework AP message buffer allocation
s390/ap: Introduce ap message buffer pool
s390/zcrypt: Avoid alloc and copy of ep11 targets if kernelspace cprb
s390/ap/zcrypt: New xflag parameter
s390/zcrypt: Introduce cprb mempool for cca misc functions
s390/zcrypt: Introduce cprb mempool for ep11 misc functions
s390/zcrypt: Rework zcrypt function zcrypt_device_status_mask_ext
s390/zcrypt: Introduce pre-allocated device status array for cca misc
s390/zcrypt: Introduce pre-allocated device status array for ep11 misc
s390/zcrypt: Remove unused functions from cca misc
s390/zcrypt: Remove CCA and EP11 card and domain info caches
s390/zcrypt: Rework cca findcard() implementation and callers
s390/zcrypt: Rework ep11 findcard() implementation and callers
s390/zcrypt: Rework cca misc functions kmallocs to use the cprb
mempool
s390/zcrypt: Propagate xflags argument with cca_get_info()
s390/zcrypt: Locate ep11_domain_query_info onto the stack instead of
kmalloc
s390/zcrypt: Rework ep11 misc functions to use cprb mempool
s390/pkey: Rework CCA pkey handler to use stack for small memory
allocs
s390/pkey: Rework EP11 pkey handler to use stack for small memory
allocs
s390/uv: Rename find_secret() to uv_find_secret() and publish
s390/pkey: Use preallocated memory for retrieve of UV secret metadata
s390/uv: Remove uv_get_secret_metadata function
s390/pkey: Provide and pass xflags within pkey and zcrypt layers
Add a new parameter xflags to the in-kernel API function
pkey_key2protkey(). Currently there is only one flag supported:
arch/s390/crypto/paes_s390.c | 6 +-
arch/s390/include/asm/pkey.h | 15 +-
arch/s390/include/asm/uv.h | 5 +-
arch/s390/kernel/uv.c | 47 +--
drivers/s390/crypto/ap_bus.c | 74 ++++
drivers/s390/crypto/ap_bus.h | 30 +-
drivers/s390/crypto/pkey_api.c | 50 +--
drivers/s390/crypto/pkey_base.c | 34 +-
drivers/s390/crypto/pkey_base.h | 37 +-
drivers/s390/crypto/pkey_cca.c | 134 ++++---
drivers/s390/crypto/pkey_ep11.c | 117 +++---
drivers/s390/crypto/pkey_pckmo.c | 9 +-
drivers/s390/crypto/pkey_sysfs.c | 4 +-
drivers/s390/crypto/pkey_uv.c | 43 ++-
drivers/s390/crypto/zcrypt_api.c | 164 ++++++---
drivers/s390/crypto/zcrypt_api.h | 16 +-
drivers/s390/crypto/zcrypt_ccamisc.c | 489 +++++++++----------------
drivers/s390/crypto/zcrypt_ccamisc.h | 49 +--
drivers/s390/crypto/zcrypt_cex4.c | 39 +-
drivers/s390/crypto/zcrypt_ep11misc.c | 457 +++++++++++------------
drivers/s390/crypto/zcrypt_ep11misc.h | 27 +-
drivers/s390/crypto/zcrypt_msgtype50.c | 36 +-
drivers/s390/crypto/zcrypt_msgtype6.c | 109 +++---
23 files changed, 968 insertions(+), 1023 deletions(-)
base-commit: bffb31040cb61aa72de8ffac655fe1459d581505
--
2.43.0
next reply other threads:[~2025-04-15 14:24 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 14:24 Harald Freudenberger [this message]
2025-04-15 14:24 ` [PATCH v5 01/25] s390/ap: Move response_type struct into ap_msg struct Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 02/25] s390/ap/zcrypt: Rework AP message buffer allocation Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 03/25] s390/ap: Introduce ap message buffer pool Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 04/25] s390/zcrypt: Avoid alloc and copy of ep11 targets if kernelspace cprb Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 05/25] s390/ap/zcrypt: New xflag parameter Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 06/25] s390/zcrypt: Introduce cprb mempool for cca misc functions Harald Freudenberger
2025-04-15 15:07 ` Heiko Carstens
2025-04-16 9:39 ` Harald Freudenberger
2025-04-16 9:06 ` Holger Dengler
2025-04-15 14:24 ` [PATCH v5 07/25] s390/zcrypt: Introduce cprb mempool for ep11 " Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 08/25] s390/zcrypt: Rework zcrypt function zcrypt_device_status_mask_ext Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 09/25] s390/zcrypt: Introduce pre-allocated device status array for cca misc Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 10/25] s390/zcrypt: Introduce pre-allocated device status array for ep11 misc Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 11/25] s390/zcrypt: Remove unused functions from cca misc Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 12/25] s390/zcrypt: Remove CCA and EP11 card and domain info caches Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 13/25] s390/zcrypt: Rework cca findcard() implementation and callers Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 14/25] s390/zcrypt: Rework ep11 " Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 15/25] s390/zcrypt: Rework cca misc functions kmallocs to use the cprb mempool Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 16/25] s390/zcrypt: Propagate xflags argument with cca_get_info() Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 17/25] s390/zcrypt: Locate ep11_domain_query_info onto the stack instead of kmalloc Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 18/25] s390/zcrypt: Rework ep11 misc functions to use cprb mempool Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 19/25] s390/pkey: Rework CCA pkey handler to use stack for small memory allocs Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 20/25] s390/pkey: Rework EP11 " Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 21/25] s390/uv: Rename find_secret() to uv_find_secret() and publish Harald Freudenberger
2025-04-15 14:24 ` [PATCH v5 22/25] s390/pkey: Use preallocated memory for retrieve of UV secret metadata Harald Freudenberger
2025-04-15 14:52 ` Heiko Carstens
2025-04-16 8:58 ` Steffen Eiden
2025-04-15 14:24 ` [PATCH v5 23/25] s390/uv: Remove uv_get_secret_metadata function Harald Freudenberger
2025-04-16 9:00 ` Steffen Eiden
2025-04-16 9:25 ` Holger Dengler
2025-04-15 14:24 ` [PATCH v5 24/25] s390/pkey: Provide and pass xflags within pkey and zcrypt layers Harald Freudenberger
2025-04-16 9:36 ` Holger Dengler
2025-04-15 14:24 ` [PATCH v5 25/25] Add a new parameter xflags to the in-kernel API function pkey_key2protkey(). Currently there is only one flag supported: Harald Freudenberger
2025-04-16 9:39 ` Holger Dengler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250415142438.118474-1-freude@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=dengler@linux.ibm.com \
--cc=fcallies@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=ifranzki@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=seiden@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox