On 5/5/23 18:40, Eric Biggers wrote:
On Fri, May 05, 2023 at 08:15:44AM -0400, Sweet Tea Dorminy wrote: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.ext4 and f2fs just don't use inline data on encrypted files. I.e. when an encrypted file is created, it always uses non-inline data. Is that an option for btrfs?
It's not impossible (though it's been viewed as a fair deficiency in last year's changesets), but it's not the only user of data needing encryption stored inline instead of separately:
For the verity metadata, how are you thinking of encrypting it, exactly? Verity metadata is immutable once written, so surely it avoids many of the issues you are dealing with for extents? It should just need one key, and that key could be set up at file open time. So I don't think it will need the key pool at all?
Yes, it should be able to use whatever the interface is for extent encryption, whether that uses pooled keys or something else. However, btrfs stores verity data in 2k chunks in the tree, similar to inline data, so it has the same difficulties.
(I realized after sending that we also want to encrypt xattrs, which are similarly stored as items in the tree instead of blocks on disk.)
We could have separate pools for inline and non-inline prepared keys (or not pool inline keys at all?)
Thanks! Sweet Tea
|