From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: [RFC ONLY 00/23] btrfs: add fscrypt integration
Date: Wed, 13 Jul 2022 06:29:33 -0400 [thread overview]
Message-ID: <cover.1657707686.git.sweettea-kernel@dorminy.me> (raw)
This is a first, partial draft of 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 simplest
case, non-compressed data extents. My goal in sending out this RFC is to
get feedback from btrfs folks 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.
Known issues are a couple of compile warnings; a mysterious EUCLEAN
return on file read that I've been trying to hunt down; no prevention of
other policies being used with btrfs, and probably other bugs and
missing code; I've been hunting bugs for the past month and keep finding
more, which is why this is so much later than I hoped last month.
Not sent out in this patchset are encryption for inline data extents,
verity items, and compressed data.
Also available as a branch at [2].
Feedback heartily appreciated.
[1] https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@relinquished.localdomain/
[2] https://github.com/sweettea/btrfs-fscrypt/tree/draft-for-rfc
Omar Sandoval (12):
btrfs: change btrfs_insert_file_extent() to btrfs_insert_hole_extent()
btrfs: rename dir_item's dir_type field to dir_flags
btrfs: add new FT_FSCRYPT flag for directories.
btrfs: explicitly keep track of file extent item size.
btrfs: factor out a memcmp for two extent_buffers.
btrfs: factor a fscrypt_name matching method
fscrypt: add fscrypt_have_same_policy() to check inode's compatibility
btrfs: disable various operations on encrypted inodes
btrfs: Add new FEATURE_INCOMPAT_FSCRYPT feature flag.
btrfs: reuse encrypted filename hash when possible.
btrfs: implement fscrypt ioctls
btrfs: adapt directory read and lookup to potentially encrypted
filenames
Sweet Tea Dorminy (11):
btrfs: use fscrypt_name's instead of name/len everywhere.
btrfs: setup fscrypt_names from dentrys using helper
fscrypt: expose fscrypt_nokey_name
fscrypt: expose a method to check whether a fscrypt_name is encrypted.
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.
fscrypt: Add new encryption policy for btrfs.
btrfs: add iv generation function
btrfs: enable encryption for normal file extent data
fs/btrfs/Makefile | 1 +
fs/btrfs/btrfs_inode.h | 3 +
fs/btrfs/ctree.h | 122 +++++--
fs/btrfs/delayed-inode.c | 48 ++-
fs/btrfs/delayed-inode.h | 9 +-
fs/btrfs/dir-item.c | 115 ++++---
fs/btrfs/extent_io.c | 139 +++++++-
fs/btrfs/extent_io.h | 6 +
fs/btrfs/extent_map.h | 8 +
fs/btrfs/file-item.c | 41 ++-
fs/btrfs/file.c | 15 +-
fs/btrfs/fscrypt.c | 222 +++++++++++++
fs/btrfs/fscrypt.h | 49 +++
fs/btrfs/inode-item.c | 84 ++---
fs/btrfs/inode-item.h | 14 +-
fs/btrfs/inode.c | 551 +++++++++++++++++++++++---------
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 | 41 ++-
fs/btrfs/tree-checker.c | 56 +++-
fs/btrfs/tree-log.c | 307 ++++++++++--------
fs/btrfs/tree-log.h | 4 +-
fs/btrfs/xattr.c | 21 +-
fs/crypto/crypto.c | 28 +-
fs/crypto/fname.c | 56 +---
fs/crypto/fscrypt_private.h | 4 +-
fs/crypto/inline_crypt.c | 20 +-
fs/crypto/keysetup.c | 6 +
fs/crypto/policy.c | 34 +-
include/linux/fscrypt.h | 67 +++-
include/uapi/linux/btrfs.h | 1 +
include/uapi/linux/btrfs_tree.h | 26 ++
include/uapi/linux/fscrypt.h | 1 +
40 files changed, 1767 insertions(+), 619 deletions(-)
create mode 100644 fs/btrfs/fscrypt.c
create mode 100644 fs/btrfs/fscrypt.h
--
2.35.1
next reply other threads:[~2022-07-13 10:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 10:29 Sweet Tea Dorminy [this message]
2022-07-13 10:29 ` [RFC ONLY 01/23] btrfs: change btrfs_insert_file_extent() to btrfs_insert_hole_extent() Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 02/23] btrfs: rename dir_item's dir_type field to dir_flags Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 03/23] btrfs: add new FT_FSCRYPT flag for directories Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 04/23] btrfs: explicitly keep track of file extent item size Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 05/23] btrfs: factor out a memcmp for two extent_buffers Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 06/23] btrfs: use fscrypt_name's instead of name/len everywhere Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 07/23] btrfs: setup fscrypt_names from dentrys using helper Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 08/23] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 09/23] fscrypt: expose a method to check whether a fscrypt_name is encrypted Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 10/23] btrfs: factor a fscrypt_name matching method Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 11/23] fscrypt: add fscrypt_have_same_policy() to check inode's compatibility Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 12/23] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 13/23] btrfs: add fscrypt operation table to superblock Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 14/23] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 15/23] btrfs: add a subvolume flag for whole-volume encryption Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 16/23] btrfs: translate btrfs encryption flags and encrypted inode flag Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 17/23] fscrypt: Add new encryption policy for btrfs Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 18/23] btrfs: add iv generation function Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 19/23] btrfs: Add new FEATURE_INCOMPAT_FSCRYPT feature flag Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 20/23] btrfs: reuse encrypted filename hash when possible Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 21/23] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 22/23] btrfs: adapt directory read and lookup to potentially encrypted filenames Sweet Tea Dorminy
2022-07-13 10:29 ` [RFC ONLY 23/23] btrfs: enable encryption for normal file extent data Sweet Tea Dorminy
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=cover.1657707686.git.sweettea-kernel@dorminy.me \
--to=sweettea-kernel@dorminy.me \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
/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