Re: [PATCH v3 0/7] Fix bio splitting by the crypto fallback code

[Christoph Hellwig <hch@lst.de>]

On Tue, Jul 15, 2025 at 09:44:56PM +0000, Eric Biggers wrote:
> Overall, it's a bit frustrating seeing these patches go by that propose
> to silently leave data unencrypted when upper layers requested that it
> be encrypted.  IMO this is actually a point against handling encryption
> in the block layer...  The whole point of storage encryption (whether
> fscrypt, dm-crypt, dm-inlinecrypt, or something else) is that the data
> is actually encrypted.  But if the actual encryption is done using code
> whose developers / maintainers don't really consider encryption to be a
> priority, that's not a great place to be.

Getting back to this.  While the ton is a bit snarky, it brings up a good
point.  Relying on the block layer to ensure that data is always
encrypted seems like a bad idea, given that is really not what the block
layer is about, and definitively not high on the mind of anyone touching
the code.  So I would not want to rely on the block layer developers to
ensure that data is encrypted properly through APIs not one believes part
that mission.

So I think you'd indeed be much better off not handling the (non-inline)
incryption in the block layer.

Doing that in fact sounds pretty easy - instead of calling the
blk-crypto-fallback code from inside the block layer, call it from the
callers instead of submit_bio when inline encryption is not actually
supported, e.g.

	if (!blk_crypto_config_supported(bdev, &crypto_cfg))
		blk_crypto_fallback_submit_bio(bio);
	else
		submit_bio(bio);

combined with checks in the low-level block code that we never get a
crypto context into the low-level submission into ->submit_bio or
->queue_rq when not supported.

That approach not only is much easier to verify for correct encryption
operation, but also makes things like bio splitting and the required
memory allocation for it less fragile.