On 2025-09-12 10:08, Ingo Franzki wrote:
On 11.09.2025 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?
Well, dm-integrity can use PHMAC and this works (with you patches) as
confirmed in this mail thread.
I don't think we have other non-dm-crypt or non-dm-integrity related
workload.
We could probably come up with a test program using AF_ALG that uses
PHMAC.
@Harald: Do you possibly have such already?
I do have. But still it only runs on a s390 platform. And for the qemu
s390
emulation - all the cpacf stuff is not covered. I think the better
approach
is really some kind of a pseudo module which offers some pseudo phmac
for
x64. Let me see how this can be done.
Otherwise, would it be possible to give us a virtual machine on the
mainframe to debug this issue?
@Harald: What do you think, could this be possible?
Hm - I have my doubts that this is possible.
Mikulas
