linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).