All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald Freudenberger <freude@linux.ibm.com>
To: Milan Broz <gmazyland@gmail.com>
Cc: Ingo Franzki <ifranzki@linux.ibm.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	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
Subject: Re: [PATCH v2 0/7] dm-integrity: asynchronous hash support
Date: Tue, 09 Sep 2025 15:51:38 +0200	[thread overview]
Message-ID: <76c330493c036317755838d2dfce2de0@linux.ibm.com> (raw)
In-Reply-To: <bd535ddb-b9b0-4404-81ba-4e6f526429d5@gmail.com>

On 2025-09-09 14:15, Milan Broz wrote:
> On 9/9/25 1:50 PM, Ingo Franzki wrote:
>> On 09.09.2025 13:47, Milan Broz wrote:
>>> On 9/9/25 1:18 PM, Ingo Franzki wrote:
>>>>> 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.
>>> 
>>> Please report it as cryptsetup issue with a reproducer so we can 
>>> later check it.
>> 
>> I don't think its a cryptsetup bug, its rather that dm-crypt is 
>> missing something to deal with async HMAC ciphers.
>> The point is that PHMAC is a async-only cipher, with no sync variant.
> 
> I know, but there is no tracker for dm-crypt and what I like to have
> some kind of upstream CI testing for PHMAC/PAES
> even without mainframe hw (we already talked about a fake cipher 
> module).

Let me think about this a bit... You are suggesting a test kernel module 
for
e.g. x64 which acts like the phmac/paes implementation in a asynchronous 
way.
I'll discuss this with Ingo.

> 
> It is not an real issue as PHMAC is neither in released kernel nor in
> cryptsetup yet, but we should have a test
> coverage once it is merged.
> 
> On the other side, the async thing is a real pain, is there any plan
> to switch to something better in future
> (for dm-crypt and dm-integrity)?
> 

Well, as of now all the s390 pkey things are by nature asynchronous. 
Which
means at any time the key may get invalid. It is in the end a hardware 
backed
key and thus if the hardware is changed (for example a 'live' guest 
migration)
the key runs invalid and needs to be re-derived or re-fetched. I don't 
see a
way to hide this and have a synchronous implementation instead.

I think on the contrary the need for asynchronous algorithms will 
increase.
More and more platforms run virtual machines which exploit special 
hardware
like AI accelerators and crypto co-processors and do support live guest 
migration.

Well, that's future. However, it would be nice to have at least one 
asynchronous
algorithm implementation available on a broad platform like x64 or arm 
maybe only
for test of the dm-integrity layer.

> Thanks,
> Milan

  parent reply	other threads:[~2025-09-09 13:51 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 [this message]
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
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=76c330493c036317755838d2dfce2de0@linux.ibm.com \
    --to=freude@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=gmazyland@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ifranzki@linux.ibm.com \
    --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.