All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Franzki <ifranzki@linux.ibm.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Biggers <ebiggers@kernel.org>,
	dengler@linux.ibm.com, linux-s390@vger.kernel.org,
	dm-devel@lists.linux.dev, agk@redhat.com, snitzer@kernel.org,
	Milan Broz <gmazyland@gmail.com>,
	freude@linux.ibm.com
Subject: Re: [PATCH v2 0/7] dm-integrity: asynchronous hash support
Date: Fri, 19 Sep 2025 08:53:11 +0200	[thread overview]
Message-ID: <ed4eba43-9d13-4875-a264-233879733bfb@linux.ibm.com> (raw)
In-Reply-To: <f799d7ab97470f2529b8dcb5566fd673@linux.ibm.com>

On 18.09.2025 17:00, Harald Freudenberger wrote:
> On 2025-09-11 17:58, Mikulas Patocka wrote:
>> On Thu, 11 Sep 2025, Ingo Franzki wrote:
>>
>>> >> So, it looks like a dm-crypt bug.
>>> >>
>>> >> Please, revert my patches and run the same test on a clean 6.17.0-rc5 just
>>> >> to verify that the patches do not introduce the bug.
>>> >
>>> > With your patches reverted the combined mode fails the same way as with your patches.
>>> > So they did not introduce the bug.
>>>
>>> Mikulas, do you have any idea what could be causing this errors?
>>> Is it that dm-crypt is not properly dealing with async-only HMAC ciphers?
>>> Async-only encryption ciphers seem to work fine in dm-crypt, since LUKS with PAES (but no integrity) works fine, and PAES is an async-onky cipher.
>>> LUKS with sync-HMAC ciphers (e.g. clear key HMAC) also works fine, even in combination with PAES.
>>
>> Yes, I think that it's a problem with async HMAC. The bug is probably
>> either in dm-crypt or in the crypto library.
>>
>> Do you have some other (non-dm-crypt-related) workload that uses the
>> async authentication, so that we can determine whether the bug is in
>> dm-crypt or crypto?
>>
>> Otherwise, would it be possible to give us a virtual machine on the
>> mainframe to debug this issue?
>>
>> Mikulas
> 
> So here is now an out-of-tree kernel module build which offers a pseudo phmac-sha256
> for testing and debugging purpose. In the end this is just a asynch (ahash) wrapper
> around the hmac-sha256 shash crypto subsystem implementation. It should compile and
> be usable on all platforms (s390, x64, arm, ...).
> 
> I ran dm-integrity tests with this and all worked fine. Ingo ran dm-crypt tests
> where he combined aes-cbc encryption with phmac-sha256 integrity and saw hangs
> on cryptsetup open. He also reported that these issues are different to what he
> saw with the 'real' phmac in combination with aes encryption. A short glimpse gives
> me the impression that there is a job blocking the system's workqueue. However, I
> could not find any indication that the pseudo phmac is not working properly.

Here is what I did (after insmod'ing the pseudo phmac cipher).
I did this on a s390x system, but it should behave the same on x86.

# cryptsetup luksFormat --type luks2 --integrity phmac-sha256 --integrity-key-size 256  /dev/loop0
# cryptsetup luksOpen /dev/loop0 int-loop

Note: To use the above cryptsetup commands with phmac you might need the code from this cryptsetup PR, otherwise it won't accept phmac as integrity algorithm: https://gitlab.com/cryptsetup/cryptsetup/-/merge_requests/693

The luksOpen step hangs forever and the following messages are shown in syslog after a while:

Sep 19 02:43:29 fedora systemd-udevd[500]: dm-1: Worker [2720] processing SEQNUM=1272 is taking a long time
Sep 19 02:45:29 fedora systemd-udevd[500]: dm-1: Worker [2720] processing SEQNUM=1272 killed

Still the luksOpen keeps hanging, and a lot of kworkers are hanging around as well: 

# ps -ef
...
root        2679    1987  2 02:42 pts/0    00:00:04 cryptsetup luksOpen /dev/loop0 int-loop
root        2712       2  0 02:42 ?        00:00:00 [kworker/R-kdmflush/251:0]
root        2713       2  0 02:42 ?        00:00:00 [kworker/R-dm-integrity-metadata]
root        2714       2  0 02:42 ?        00:00:00 [kworker/R-dm-integrity-wait]
root        2715       2  0 02:42 ?        00:00:00 [kworker/R-dm-integrity-offload]
root        2716       2  0 02:42 ?        00:00:00 [kworker/R-dm-integrity-commit]
root        2717       2  0 02:42 ?        00:00:00 [kworker/R-dm-integrity-writer]
root        2718     500  0 02:42 ?        00:00:00 (udev-worker)
root        2719     500  0 02:42 ?        00:00:00 (udev-worker)
root        2720     500  0 02:42 ?        00:00:00 [(udev-worker)]
root        2726       2  0 02:42 ?        00:00:00 [kworker/R-kdmflush/251:1]
root        2727       2  0 02:42 ?        00:00:00 [kworker/R-kcryptd_io-251:1-1]
root        2728       2  0 02:42 ?        00:00:00 [kworker/R-kcryptd-251:1-1]
root        2729       2  0 02:42 ?        00:00:00 [dmcrypt_write/251:1]
...

# dmsetup table
int-loop: 0 351128 crypt capi:authenc(phmac(sha256),xts(aes))-plain64 :96:logon:cryptsetup:239c87ad-8c23-4cdb-943f-947737e9cf5c-d0 0 251:0 0 2 integrity:32:aead integrity_key_size:32
int-loop_dif: 0 351128 integrity 7:0 32768 32 J 6 interleave_sectors:32768 buffer_sectors:128 journal_sectors:3168 journal_watermark:50 commit_time:10000 fix_padding

# lsblk
NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
loop0            7:0    0   200M  0 loop
└─int-loop_dif 251:0    0 171.4M  0 crypt


> 
> For instructions on how to build and use the module see the README in the tgz archive.
> 
> Thanks to all
> Harald Freudenberger
> 
> 


-- 
Ingo Franzki
eMail: ifranzki@linux.ibm.com  
Tel: ++49 (0)7031-16-4648
Linux on IBM Z Development, Schoenaicher Str. 220, 71032 Boeblingen, Germany

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Gregor Pillen
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-09-19  6:53 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-08 13:16 [PATCH v2 0/7] dm-integrity: asynchronous hash support Mikulas Patocka
2025-09-08 13:16 ` [PATCH v2 1/7] dm-integrity: use internal variable for digestsize Mikulas Patocka
2025-09-08 13:16 ` [PATCH v2 2/7] dm-integrity: replace bvec_kmap_local with kmap_local_page Mikulas Patocka
2025-09-08 13:16 ` [PATCH v2 3/7] dm-integrity: introduce integrity_kmap and integrity_kunmap Mikulas Patocka
2025-09-08 13:16 ` [PATCH v2 4/7] dm-integrity: allocate the recalculate buffer with kmalloc Mikulas Patocka
2025-09-08 13:16 ` [PATCH v2 5/7] dm-integrity: add the "offset" argument Mikulas Patocka
2025-09-08 13:16 ` [PATCH v2 6/7] dm-integrity: rename internal_hash Mikulas Patocka
2025-09-08 13:16 ` [PATCH v2 7/7] dm-integrity: enable asynchronous hash interface Mikulas Patocka
2025-09-09  9:04 ` [PATCH v2 0/7] dm-integrity: asynchronous hash support Ingo Franzki
2025-09-09  9:42   ` Mikulas Patocka
2025-09-09 11:18     ` Ingo Franzki
2025-09-09 11:47       ` Milan Broz
2025-09-09 11:50         ` Ingo Franzki
2025-09-09 12:15           ` Milan Broz
2025-09-09 12:23             ` Ingo Franzki
2025-09-09 12:40               ` Milan Broz
2025-09-09 13:51             ` Harald Freudenberger
2025-09-09 14:12               ` Milan Broz
2025-09-11 13:43       ` Ingo Franzki
2025-09-11 15:58         ` Mikulas Patocka
2025-09-12  8:08           ` Ingo Franzki
2025-09-15  9:26             ` Harald Freudenberger
2025-09-18 15:00           ` Harald Freudenberger
2025-09-19  6:53             ` Ingo Franzki [this message]
2025-09-22 19:08             ` [PATCH] crypto/authenc: don't return -EBUSY when enqueuing the hash request Mikulas Patocka
2025-09-23  3:47               ` Herbert Xu
2025-09-23 11:14                 ` Mikulas Patocka
2025-09-23 14:36                   ` Mikulas Patocka
2025-09-23 15:17                   ` Herbert Xu
2025-09-24 10:20                     ` [PATCH] crypto: authenc - Correctly pass EINPROGRESS back up to the caller Herbert Xu
2025-09-24 13:17                       ` Ingo Franzki
2025-11-25 14:02                     ` [PATCH] crypto/authenc: don't return -EBUSY when enqueuing the hash request Mikulas Patocka
2025-11-26  5:16                       ` Herbert Xu
2025-09-09 13:36 ` [PATCH v2 0/7] dm-integrity: asynchronous hash support Harald Freudenberger

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=ed4eba43-9d13-4875-a264-233879733bfb@linux.ibm.com \
    --to=ifranzki@linux.ibm.com \
    --cc=agk@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dengler@linux.ibm.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=ebiggers@kernel.org \
    --cc=freude@linux.ibm.com \
    --cc=gmazyland@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-s390@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=snitzer@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.