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.
