Message ID | cover.1658623319.git.sweettea-kernel@dorminy.me (mailing list archive) |
---|---|
Headers | show |
Series | btrfs: add fscrypt integration | expand |
Hello, I see no comment on this RFC. Is there any next version? Thanks, Usama On 7/24/22 5:53 AM, Sweet Tea Dorminy wrote: > This is a draft set of changes adding fscrypt integration to btrfs. > > Last October, Omar sent out a design document for having fscrypt > integration with btrfs [1]. In summary, it proposes btrfs storing its > own encryption IVs on a per-file-extent basis. fscrypt usually encrypts > files using an IV derived from per-inode information; this would prevent > snapshotting or reflinking or data relocation for btrfs, but by using an > IV associated with each file extent, all the inodes sharing a particular > key and file extent may decrypt successfully. > > This series starts implementing it on the kernel side for the simple > case, non-compressed data extents. My goal in sending out this RFC is to > get feedback on whether these are going in a reasonable direction; while > there are a couple of additional parts, they're fundamentally minor > compared to this. > > Not included are a couple of minor changes to btrfs-progs; additionally, > none of the fscrypt tool changes needed to use the new encryption policy > are included. Obviously, additional fstests will be needed. Also not yet > included are encryption for inline data extents, verity items, and > compressed data. > > [1] > https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@relinquished.localdomain/ > > Changelog: > > v2: > - Fixed all warnings and known incorrectnesses. > - Split fscrypt changes into their own patchset: > https://lore.kernel.org/linux-fscrypt/cover.1658623235.git.sweettea-kernel@dorminy.me > - Combined and reordered changes so that enabling fscrypt is the last change. > - Removed unnecessary factoring. > - Split a cleanup change off. > > v1: > - https://lore.kernel.org/linux-btrfs/cover.1657707686.git.sweettea-kernel@dorminy.me > > Omar Sandoval (13): > btrfs: store directories' encryption state > btrfs: factor a fscrypt_name matching method > btrfs: disable various operations on encrypted inodes > btrfs: add fscrypt operation table to superblock > btrfs: start using fscrypt hooks. > btrfs: add a subvolume flag for whole-volume encryption > btrfs: translate btrfs encryption flags and encrypted inode flag. > btrfs: store an IV per encrypted normal file extent > btrfs: Add new FEATURE_INCOMPAT_FSCRYPT feature flag. > btrfs: reuse encrypted filename hash when possible. > btrfs: adapt directory read and lookup to potentially encrypted > filenames > btrfs: encrypt normal file extent data if appropriate > btrfs: implement fscrypt ioctls > > Sweet Tea Dorminy (3): > btrfs: use fscrypt_name's instead of name/len everywhere. > btrfs: setup fscrypt_names from dentrys using helper > btrfs: add iv generation function for fscrypt > > fs/btrfs/Makefile | 1 + > fs/btrfs/btrfs_inode.h | 3 + > fs/btrfs/ctree.h | 113 +++++-- > fs/btrfs/delayed-inode.c | 48 ++- > fs/btrfs/delayed-inode.h | 9 +- > fs/btrfs/dir-item.c | 120 ++++--- > fs/btrfs/extent_io.c | 93 +++++- > fs/btrfs/extent_io.h | 2 + > fs/btrfs/extent_map.h | 8 + > fs/btrfs/file-item.c | 20 +- > fs/btrfs/file.c | 11 +- > fs/btrfs/fscrypt.c | 224 +++++++++++++ > fs/btrfs/fscrypt.h | 49 +++ > fs/btrfs/inode-item.c | 84 ++--- > fs/btrfs/inode-item.h | 14 +- > fs/btrfs/inode.c | 547 ++++++++++++++++++++++++-------- > fs/btrfs/ioctl.c | 80 ++++- > fs/btrfs/ordered-data.c | 12 +- > fs/btrfs/ordered-data.h | 3 +- > fs/btrfs/print-tree.c | 4 +- > fs/btrfs/props.c | 11 +- > fs/btrfs/reflink.c | 8 + > fs/btrfs/root-tree.c | 20 +- > fs/btrfs/send.c | 141 ++++---- > fs/btrfs/super.c | 8 +- > fs/btrfs/transaction.c | 43 ++- > fs/btrfs/tree-checker.c | 56 +++- > fs/btrfs/tree-log.c | 261 ++++++++------- > fs/btrfs/tree-log.h | 4 +- > fs/btrfs/xattr.c | 21 +- > include/uapi/linux/btrfs.h | 1 + > include/uapi/linux/btrfs_tree.h | 26 ++ > 32 files changed, 1525 insertions(+), 520 deletions(-) > create mode 100644 fs/btrfs/fscrypt.c > create mode 100644 fs/btrfs/fscrypt.h >
On Thu, Oct 13, 2022 at 05:14:09PM +0500, Muhammad Usama Anjum wrote: > Hello, > > I see no comment on this RFC. Is there any next version? Yes, there will be another version.