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@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
