From: Holger Dengler <dengler@linux.ibm.com>
To: Harald Freudenberger <freude@linux.ibm.com>,
herbert@gondor.apana.org.au, ifranzki@linux.ibm.com,
fcallies@linux.ibm.com
Cc: linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH v4 2/3] s390/crypto: Rework protected key AES for true asynch support
Date: Wed, 14 May 2025 10:33:13 +0200 [thread overview]
Message-ID: <cffdc85b-ca01-41da-9cb8-390322f20253@linux.ibm.com> (raw)
In-Reply-To: <20250509102402.27287-3-freude@linux.ibm.com>
On 09/05/2025 12:24, Harald Freudenberger wrote:
> This is a complete rework of the protected key AES (PAES) implementation.
> The goal of this rework is to implement the 4 modes (ecb, cbc, ctr, xts)
> in a real asynchronous fashion:
> - init(), exit() and setkey() are synchronous and don't allocate any memory.
Please wrap this line (checkpatch complains, it's too long).
> - the encrypt/decrypt functions first try to do the job in a synchronous
> manner. If this fails, for example the protected key got invalid caused
> by a guest suspend/resume or guest migration action, the encrypt/decrypt
> is transferred to an instance of the crypto engine (see below) for
> asynchronous processing.
> These postponed requests are then handled by the crypto engine by
> invoking the do_one_request() callback but may of course again run into
> a still not converted key or the key is getting invalid. If the key is
> still not converted, the first thread does the conversion and updates
> the key status in the transformation context. The conversion is
> invoked via pkey API with a new flag PKEY_XFLAG_NOMEMALLOC.
> Note that once there is an active requests enqueued to get async
> processed via crypto engine, further requests also need to go via
> crypto engine to keep the request sequence.
>
> This patch together with the pkey/zcrypt/AP extensions to support
> the new PKEY_XFLAG_NOMEMMALOC should toughen the paes crypto algorithms
> to truly meet the requirements for in-kernel skcipher implementations
> and the usage patterns for the dm-crypt and dm-integrity layers.
>
> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
With the line wrap and the typos fixed
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
> ---
> arch/s390/crypto/paes_s390.c | 1812 ++++++++++++++++++++++++----------
> 1 file changed, 1270 insertions(+), 542 deletions(-)
>
> diff --git a/arch/s390/crypto/paes_s390.c b/arch/s390/crypto/paes_s390.c
> index 1f62a9460405..596698ce7084 100644
> --- a/arch/s390/crypto/paes_s390.c
> +++ b/arch/s390/crypto/paes_s390.c
[...]
> @@ -89,214 +129,367 @@ static inline u32 make_clrkey_token(const u8 *ck, size_t cklen, u8 *dest)
> return sizeof(*token) + cklen;
> }
>
> -static inline int _key_to_kb(struct key_blob *kb,
> - const u8 *key,
> - unsigned int keylen)
> +/*
> + * paes_ctx_setkey() - Set key value into context, maybe construct
> + * a clear key token digestable by pkey from a clear key value.
typo: digestible
> + */
> +static inline int paes_ctx_setkey(struct s390_paes_ctx *ctx,
> + const u8 *key, unsigned int keylen)
[...]
> +/*
> + * pxts_ctx_setkey() - Set key value into context, maybe construct
> + * a clear key token digestable by pkey from a clear key value.
typo: digestible
> + */
> +static inline int pxts_ctx_setkey(struct s390_pxts_ctx *ctx,
> + const u8 *key, unsigned int keylen)
[...]
> {
> size_t cklen = keylen / 2;
>
--
Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
dengler@linux.ibm.com
next prev parent reply other threads:[~2025-05-14 8:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-09 10:23 [PATCH v4 0/3] Rework protected key AES for true asynch support Harald Freudenberger
2025-05-09 10:24 ` [PATCH v4 1/3] s390/cpacf: Rework cpacf_pcc() to return condition code Harald Freudenberger
2025-05-09 10:24 ` [PATCH v4 2/3] s390/crypto: Rework protected key AES for true asynch support Harald Freudenberger
2025-05-13 8:07 ` Herbert Xu
2025-05-14 8:33 ` Holger Dengler [this message]
2025-05-09 10:24 ` [PATCH v4 3/3] Documentation: crypto_engine: Update and extend crypto engine doc Harald Freudenberger
2025-05-14 8:40 ` 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=cffdc85b-ca01-41da-9cb8-390322f20253@linux.ibm.com \
--to=dengler@linux.ibm.com \
--cc=fcallies@linux.ibm.com \
--cc=freude@linux.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=ifranzki@linux.ibm.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.