From: Harald Freudenberger <freude@linux.ibm.com>
To: herbert@gondor.apana.org.au, dengler@linux.ibm.com,
ifranzki@linux.ibm.com, fcallies@linux.ibm.com
Cc: linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org
Subject: [PATCH v1 0/1] Rework protected key AES for true asynch support
Date: Thu, 6 Mar 2025 18:12:00 +0100 [thread overview]
Message-ID: <20250306171201.17961-1-freude@linux.ibm.com> (raw)
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() and exit() both are synchronous, don't allocate any memory and
do not sleep.
- the setkey() function initiates an asynch work to convert the key
material via pkey interface into a protected key. setkey() does
not allocate any memory and does not sleep. The asynch work is
done in an own workqueue (so not congesting any system work queues).
For the pkey API see more below.
- 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 for example a guest suspend/resume or guest migration action, the
encrypt/decrypt is pushed into the workqueue for asynchronous processing.
These asynch triggered workqueue functions of course may run again into
a still not converted key or the key is getting invalid. If the key is
still not converted, the job pushes itself into the workqueue for later
processing. If the key needs re-convert, the conversion is invoked
via pkey API. The asynch workqueue functions do not allocate any memory.
The pkey API used here - the function pkey_key2protkey() - uses
a new version of this in-kernel-API. A new flag PKEY_XFLAG_NOMEMALLOC
tells the PKEY layer (and subsidiary layers) that it must not allocate
any memory causing IO operations. Note that the patches for this
pkey/zcrypt/AP extensions are currently under review and yet not
upstream available. SO THIS PATCH DOES NOT COMPILE YET.
This patch together with the pkey/zcrypt/AP extensions 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.
Changelog:
v1 - first version. Applied and tested on top of the mentioned
pkey/zcrypt/AP changes. Selftests and multithreaded testcases
executed via AP_ALG interface run successful and even instrumented
code (with some sleeps to force asynch pathes) ran fine.
Code is good enough for a first code review and collecting feedback.
Harald Freudenberger (1):
s390/crypto: Rework protected key AES for true asynch support
arch/s390/crypto/paes_s390.c | 1482 +++++++++++++++++++++++-----------
1 file changed, 1015 insertions(+), 467 deletions(-)
--
2.43.0
next reply other threads:[~2025-03-06 17:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 17:12 Harald Freudenberger [this message]
2025-03-06 17:12 ` [PATCH v1 1/1] s390/crypto: Rework protected key AES for true asynch support Harald Freudenberger
2025-03-07 3:01 ` Herbert Xu
2025-03-07 8:26 ` Harald Freudenberger
2025-03-07 8:36 ` Herbert Xu
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=20250306171201.17961-1-freude@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=dengler@linux.ibm.com \
--cc=fcallies@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox