Message-ID: <Z-tTEjCzpgDr9a-3@gondor.apana.org.au>
Date: Tue, 1 Apr 2025 10:44:34 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: Chaining is dead

On Mon, Mar 31, 2025 at 04:56:30PM +0000, Eric Biggers wrote:
>
> With the bio and folio support in the generic crypto infrastructure, there would
> be lots of work to do with adding support in all the underlying algorithms, and
> adding tests for all the new APIs.

It doesn't need to be all that complex.  My plan is to add a fallback
template at the top, which could then be implemented by strategic
algorithms at the bottom through an extension of the skcipher walk
mechanism.

So you'd allocate "fscrypt(xts(aes))" instead of "xts(aes)", and
the xts-vaes code could simply use the normal skcipher walker with
zero changes.  The only changes needed in the aesni module is to
hook up the xts code to the new "fscrypt(xts(aes))" algorithm.

The real reason why I think this is the way to go is that the same
speed-up would apply everywhere.  So just as I could gain a 15%
speed-up with xts in fscrypt without any actual multibuffer code,
a similar speed-up is expected with gcm in networking.  In fact
if anything the speed-up could be greater there because the data
unit size is smaller at under 1500 bytes.

You see the Crypto API as the problem here, but for me the problem
is the legacy data unit size.  It's 2025 and there is no reason why
anyone should be dealing with units of 1500 or 4096 bytes.

> For hashing, users would need to allocate an array to hold the digest for every
> block in the bio or folio.  That would add an additional memory allocation to
> every I/O.  You said you'd like to fall back to a smaller buffer if the memory
> allocation fails.  But that's silly; if we have to support that anyway, we might
> as well do it that way only.  In which case the bio interface is pointless.

Sure if you decide to go down the lib/crypto route then there is
no gain.  All it means is that you can't support hardware offload,
but neither of us really care about that.

> Also note that the kernel also *already* has an abstraction layer that allows
> doing en/decryption on bios.  It's called blk-crypto, and it makes it possible
> to do the en/decryption using either inline encryption hardware (i.e., the newer
> style of crypto accelerator that is actually commonly used and doesn't use the
> Crypto API at all) or the Crypto API.  I have plans to remove the fs-layer bio
> en/decryption code from fscrypt and always use blk-crypto instead.

Thanks for the pointer, I wasn't aware of its existence.  Yes
there should definitely be only one code path for this.  So
what's stopping you from removing fscrypt right now? IOW what's
missing from blk-crypto?

> Adding bio support to the Crypto API feels duplicative of blk-crypto, and we'd
> end up with too many abstraction layers.  I think my preferred approach is that
> blk-crypto-fallback would directly call the library functions.  The legacy
> Crypto API really has no useful role to play anymore.

I'd certainly like to see that :)

> FWIW, there are also people thinking about developing inline hashing hardware,
> in which case something similar would apply to blk-integrity.

Offloading a whole bio rather than a page or two is definitely
the way to go.

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

Powered by blists - more mailing lists