public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
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


             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