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? 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? - Eric
|