As I mentioned earlier (https://lore.kernel.org/r/Y7NQ1CvPyJiGRe00@sol.localdomain), blk-crypto-fallback actually already solved the problem of caching crypto_skcipher objects for I/O. And, it's possible for a filesystem to *only* support blk-crypto, not filesystem-layer contents encryption. You'd just need to put btrfs encryption behind a new kconfig option that is automatically selected by CONFIG_FS_ENCRYPTION_INLINE_CRYPT && CONFIG_BLK_ENCRYPTION_FALLBACK. (BTW, I'm thinking of simplifying the kconfig options by removing CONFIG_FS_ENCRYPTION_INLINE_CRYPT. Then, the blk-crypto code in fs/crypto/ will be built if CONFIG_FS_ENCRYPTION && CONFIG_BLK_INLINE_ENCRYPTION.) Indeed, filesystem-layer contents encryption is a bit redundant these days now that blk-crypto-fallback exists. I'm even tempted to make ext4 and f2fs support blk-crypto only someday. That was sort of the original plan, actually... So, I'm wondering if you've considered going the blk-crypto-fallback route?
I did, and gave it a shot, but ran into problems because as far as I can tell it requires having a bio to crypt. For verity data and inline extents, there's no obvious bio, and even if we tried to construct a bio pointing at the relevant data, it's not necessarily sector- sized or aligned. I couldn't figure out a good way to make it work, but maybe it's better to special-case those or there's something I'm not seeing.
|