From: Harald Freudenberger <freude@linux.ibm.com>
To: dengler@linux.ibm.com, ifranzki@linux.ibm.com
Cc: linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org,
herbert@gondor.apana.org.au, mpatocka@redhat.com
Subject: [PATCH v1] crypto: s390/phmac - Do not modify the req->nbytes value
Date: Thu, 9 Oct 2025 18:01:10 +0200 [thread overview]
Message-ID: <20251009160110.12829-1-freude@linux.ibm.com> (raw)
There was a failure reported by the phmac only in combination
with dm-crypt where the phmac is used as the integrity check
mechanism. A pseudo phmac which was implemented just as an
asynchronous wrapper around the synchronous hmac algorithm did
not show this failure. After some debugging the reason is clear:
The crypto aead layer obvious uses the req->nbytes value after
the verification algorithm is through and finished with the
request. If the req->nbytes value has been modified the aead
layer will react with -EBADMSG to the caller (dm-crypt).
Unfortunately the phmac implementation used the req->nbytes
field on combined operations (finup, digest) to track the
state: with req->nbytes > 0 the update needs to be processed,
while req->nbytes == 0 means to do the final operation. For
this purpose the req->nbytes field was set to 0 after successful
update operation. This worked fine and all tests succeeded but
only failed with aead use as dm-crypt with verify uses it.
Fixed by a slight rework on the phmac implementation. There is
now a new field async_op in the request context which tracks
the (asynch) operation to process. So the 'state' via req->nbytes
is not needed any more and now this field is untouched and may
be evaluated even after a request is processed by the phmac
implementation.
Fixes: cbbc675506cc ("crypto: s390 - New s390 specific protected key hash phmac")
Reported-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
---
arch/s390/crypto/phmac_s390.c | 52 +++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 18 deletions(-)
diff --git a/arch/s390/crypto/phmac_s390.c b/arch/s390/crypto/phmac_s390.c
index 7ecfdc4fba2d..5d38a48cc45d 100644
--- a/arch/s390/crypto/phmac_s390.c
+++ b/arch/s390/crypto/phmac_s390.c
@@ -169,11 +169,18 @@ struct kmac_sha2_ctx {
u64 buflen[2];
};
+enum async_op {
+ OP_NOP = 0,
+ OP_UPDATE,
+ OP_FINAL,
+ OP_FINUP,
+};
+
/* phmac request context */
struct phmac_req_ctx {
struct hash_walk_helper hwh;
struct kmac_sha2_ctx kmac_ctx;
- bool final;
+ int async_op;
};
/*
@@ -610,6 +617,7 @@ static int phmac_update(struct ahash_request *req)
* using engine to serialize requests.
*/
if (rc == 0 || rc == -EKEYEXPIRED) {
+ req_ctx->async_op = OP_UPDATE;
atomic_inc(&tfm_ctx->via_engine_ctr);
rc = crypto_transfer_hash_request_to_engine(phmac_crypto_engine, req);
if (rc != -EINPROGRESS)
@@ -647,8 +655,7 @@ static int phmac_final(struct ahash_request *req)
* using engine to serialize requests.
*/
if (rc == 0 || rc == -EKEYEXPIRED) {
- req->nbytes = 0;
- req_ctx->final = true;
+ req_ctx->async_op = OP_FINAL;
atomic_inc(&tfm_ctx->via_engine_ctr);
rc = crypto_transfer_hash_request_to_engine(phmac_crypto_engine, req);
if (rc != -EINPROGRESS)
@@ -676,13 +683,16 @@ static int phmac_finup(struct ahash_request *req)
if (rc)
goto out;
+ req_ctx->async_op = OP_FINUP;
+
/* Try synchronous operations if no active engine usage */
if (!atomic_read(&tfm_ctx->via_engine_ctr)) {
rc = phmac_kmac_update(req, false);
if (rc == 0)
- req->nbytes = 0;
+ req_ctx->async_op = OP_FINAL;
}
- if (!rc && !req->nbytes && !atomic_read(&tfm_ctx->via_engine_ctr)) {
+ if (!rc && req_ctx->async_op == OP_FINAL &&
+ !atomic_read(&tfm_ctx->via_engine_ctr)) {
rc = phmac_kmac_final(req, false);
if (rc == 0)
goto out;
@@ -694,7 +704,7 @@ static int phmac_finup(struct ahash_request *req)
* using engine to serialize requests.
*/
if (rc == 0 || rc == -EKEYEXPIRED) {
- req_ctx->final = true;
+ /* req->async_op has been set to either OP_FINUP or OP_FINAL */
atomic_inc(&tfm_ctx->via_engine_ctr);
rc = crypto_transfer_hash_request_to_engine(phmac_crypto_engine, req);
if (rc != -EINPROGRESS)
@@ -855,15 +865,16 @@ static int phmac_do_one_request(struct crypto_engine *engine, void *areq)
/*
* Three kinds of requests come in here:
- * update when req->nbytes > 0 and req_ctx->final is false
- * final when req->nbytes = 0 and req_ctx->final is true
- * finup when req->nbytes > 0 and req_ctx->final is true
- * For update and finup the hwh walk needs to be prepared and
- * up to date but the actual nr of bytes in req->nbytes may be
- * any non zero number. For final there is no hwh walk needed.
+ * 1. req->async_op == OP_UPDATE with req->nbytes > 0
+ * 2. req->async_op == OP_FINUP with req->nbytes > 0
+ * 3. req->async_op == OP_FINAL
+ * For update and finup the hwh walk has already been prepared
+ * by the caller. For final there is no hwh walk needed.
*/
- if (req->nbytes) {
+ switch (req_ctx->async_op) {
+ case OP_UPDATE:
+ case OP_FINUP:
rc = phmac_kmac_update(req, true);
if (rc == -EKEYEXPIRED) {
/*
@@ -880,10 +891,11 @@ static int phmac_do_one_request(struct crypto_engine *engine, void *areq)
hwh_advance(hwh, rc);
goto out;
}
- req->nbytes = 0;
- }
-
- if (req_ctx->final) {
+ if (req_ctx->async_op == OP_UPDATE)
+ break;
+ req_ctx->async_op = OP_FINAL;
+ fallthrough;
+ case OP_FINAL:
rc = phmac_kmac_final(req, true);
if (rc == -EKEYEXPIRED) {
/*
@@ -897,10 +909,14 @@ static int phmac_do_one_request(struct crypto_engine *engine, void *areq)
cond_resched();
return -ENOSPC;
}
+ break;
+ default:
+ /* unknown/unsupported/unimplemented asynch op */
+ return -EOPNOTSUPP;
}
out:
- if (rc || req_ctx->final)
+ if (rc || req_ctx->async_op == OP_FINAL)
memzero_explicit(kmac_ctx, sizeof(*kmac_ctx));
pr_debug("request complete with rc=%d\n", rc);
local_bh_disable();
--
2.43.0
next reply other threads:[~2025-10-09 16:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-09 16:01 Harald Freudenberger [this message]
2025-10-10 7:55 ` [PATCH v1] crypto: s390/phmac - Do not modify the req->nbytes value Ingo Franzki
2025-10-10 8:40 ` Ingo Franzki
2025-10-14 9:19 ` Holger Dengler
2025-10-14 10:31 ` Harald Freudenberger
2025-10-14 10:43 ` 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=20251009160110.12829-1-freude@linux.ibm.com \
--to=freude@linux.ibm.com \
--cc=dengler@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 \
--cc=mpatocka@redhat.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;
as well as URLs for NNTP newsgroup(s).