public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Franzki <ifranzki@linux.ibm.com>
To: Harald Freudenberger <freude@linux.ibm.com>
Cc: linux-crypto@vger.kernel.org, linux-s390@vger.kernel.org,
	herbert@gondor.apana.org.au, mpatocka@redhat.com,
	dengler@linux.ibm.com
Subject: Re: [PATCH v1] crypto: s390/phmac - Do not modify the req->nbytes value
Date: Fri, 10 Oct 2025 09:55:11 +0200	[thread overview]
Message-ID: <546f224a-70b9-4108-b6f9-4ddacc305b25@linux.ibm.com> (raw)
In-Reply-To: <20251009160110.12829-1-freude@linux.ibm.com>

On 09.10.2025 18:01, Harald Freudenberger wrote:
> 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(-)

I can confirm that this fixes the failures reported at https://lore.kernel.org/dm-devel/fec83aad-c38b-4617-bb9a-0b9827125d79@linux.ibm.com/T/#u
Also, having the operation in the request context makes the code even more clear IMHO.

Tested-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM DATA Privacy Statement: https://www.ibm.com/privacy/us/en/

  reply	other threads:[~2025-10-10  7:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-09 16:01 [PATCH v1] crypto: s390/phmac - Do not modify the req->nbytes value Harald Freudenberger
2025-10-10  7:55 ` Ingo Franzki [this message]
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=546f224a-70b9-4108-b6f9-4ddacc305b25@linux.ibm.com \
    --to=ifranzki@linux.ibm.com \
    --cc=dengler@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --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