From: Muhammad Usama Anjum <usama.anjum@collabora.com>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
osandov@osandov.com, kernel-team@fb.com
Subject: Re: [PATCH RFC v2 00/16] btrfs: add fscrypt integration
Date: Thu, 13 Oct 2022 17:14:09 +0500 [thread overview]
Message-ID: <c8d135f8-8fbf-2314-9efc-ec172233150f@collabora.com> (raw)
In-Reply-To: <cover.1658623319.git.sweettea-kernel@dorminy.me>
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
>
next prev parent reply other threads:[~2022-10-13 12:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-24 0:53 [PATCH RFC v2 00/16] btrfs: add fscrypt integration Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 01/16] btrfs: store directorys' encryption state Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 02/16] btrfs: use fscrypt_name's instead of name/len everywhere Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 03/16] btrfs: setup fscrypt_names from dentrys using helper Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 04/16] btrfs: factor a fscrypt_name matching method Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 05/16] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 06/16] btrfs: add fscrypt operation table to superblock Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 07/16] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 08/16] btrfs: add a subvolume flag for whole-volume encryption Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 09/16] btrfs: translate btrfs encryption flags and encrypted inode flag Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 10/16] btrfs: add iv generation function for fscrypt Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 11/16] btrfs: store an IV per encrypted normal file extent Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 12/16] btrfs: Add new FEATURE_INCOMPAT_FSCRYPT feature flag Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 13/16] btrfs: reuse encrypted filename hash when possible Sweet Tea Dorminy
2022-07-24 0:53 ` [PATCH RFC v2 14/16] btrfs: adapt directory read and lookup to potentially encrypted filenames Sweet Tea Dorminy
2022-07-24 0:54 ` [PATCH RFC v2 15/16] btrfs: encrypt normal file extent data if appropriate Sweet Tea Dorminy
2022-07-24 0:54 ` [PATCH RFC v2 16/16] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2022-10-13 12:14 ` Muhammad Usama Anjum [this message]
2022-10-14 10:54 ` [PATCH RFC v2 00/16] btrfs: add fscrypt integration David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c8d135f8-8fbf-2314-9efc-ec172233150f@collabora.com \
--to=usama.anjum@collabora.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=sweettea-kernel@dorminy.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).