On Sat, Sep 2, 2023 at 1:56 AM Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx> wrote: > > For contrast purposes, this patch contains the entirety of the changes > necessary to switch between lightweight and heavyweight extents. This > patch could be dropped, or rolled into the former change, without > changing anything else. > > Lightweight extents relying on their parent inode's context for > key and policy information do take up less disk space. Additionally, > they guarantee that if inode open succeeds, then all extents will be > readable and writeable, matching the current inode-based fscrypt > behavior. > > However, heavyweight extents permit greater flexibility for future > extensions: > > - Any form of changing the key for a non-empty directory's > future writes requires that extents have some sort of policy in > addition to the nonce, which is essentially the contents of the full > fscrypt_context. > - This could be approximated using overlayfs writing to a new > encrypted directory, but this would waste space used by overwritten > data and makes it very difficult to have nested subvolumes each with > their own key, so it's very preferable to support this natively in > btrfs. > > - Scrub (verifying checksums) currently iterates over extents, > without interacting with inodes; in an authenticated encryption world, > scrub verifying authentication tags would need to iterate over inodes (a > large departure from the present) or need heavyweight extents storing > the necessary key information. > I've been thinking about this patch set a bit since it was posted, and I've got some thoughts specifically about this. A use-case that is extremely important to me is enabling background encryption of parts or the whole filesystem, but also enabling rekeying the encrypted data too. This can be necessary for a variety of reasons. This is supported in LUKS/dm-crypt and I would like to have this supported in Btrfs native encryption through fscrypt. My understanding of this (after following all the discussions and patch sets) is that heavyweight extents make this a fundamentally cheaper and safer operation because there's no need to traverse through the inodes and change them. This would be fairly expensive and create a situation where inode sharing becomes much more limited as rekeying occurs on active data while not occurring on old snapshots, for example. It's certainly a trade-off that leads to more complexity, but I think it's worth it because key properties that people rely on with Btrfs can be preserved even with encrypted data. -- 真実はいつも一つ！/ Always, there's only one truth!
|