Re: [PATCH v1 1/1] dm-integrity: Implement asynch digest support

[Herbert Xu <herbert@gondor.apana.org.au>]

On Thu, Jan 16, 2025 at 05:54:51PM +0000, Eric Biggers wrote:
>
> But in practice it's the opposite.  Making it an ahash forces users who would
> otherwise just be using shash to use ahash instead.

I think that's a good thing.  shash was a mistake and I intend to
get rid of it.  But we should not do the ahash conversion right now.
Let me finish adding virtual address support first and then we could
reassess whether this makes sense or not.

> No one is asking for it to be available to IPsec.  And this is just a MAC, not a
> cipher.  But more generally, sleepable algorithms could still be used via an
> adapter using cryptd, or by making IPsec support using a workqueue like all the
> storage encryption/integrity systems already do.  In any case this would be a
> rare (or nonexistent?) use case and should be treated as such.

If it was possible to shoehorn phmac/paes into a synchronous
algorithm I'd love to do it.  But the fact is that this requires
asynchronous communication in the *unlikely* case which means
that the best way to model is with an optional async interface.

	if (unlikely(crypto_ahash_op(...) == -EINPROGRESS))
		do async
	else
		op completed synchronously

> That won't solve all the problems with ahash, for example the per-request
> allocation.  We'll still end up with something that is worse for 99% of users,
> while also doing a very poor job supporting the 1% (even assuming it's 1% and
> not 0% which it very well might be) who actually think they want off-CPU
> hardware crypto acceleration.  Not to mention the nonsense like having
> "synchronous asynchronous hashes".

I disagree.  I want the users to start feeding ahash with more
than one unit of input.  So rather than splitting up a folio
into page-size or sector-size units, you feed the whole thing
to ahash and the data should be split up automatically and hashed
in parallel.

> I think it's time to admit that the approach you're trying to take with the
> crypto API is wrong.  This has been known for years.

The only thing I agree with you here is that an SG list-based input
format is inappropriate.  And that is why I'm adding virtual address
support to ahash (and later to skcipher).

> The primary API needs to be designed around and optimized for software crypto,
> which is what nearly everyone wants.

I agree with that completely.  However, what triggered this thread
is in fact something that is not purely software crypto because it
involves system-wide communication which could take seconds to
complete.  The original patch tried to shoehorn this into a
synchronous implementation that would just fail randomly after
waiting.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt