linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v3 00/22] btrfs: add fscrypt integration
@ 2022-10-20 16:58 Sweet Tea Dorminy
  2022-10-20 16:58 ` [PATCH v3 01/22] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
                   ` (22 more replies)
  0 siblings, 23 replies; 37+ messages in thread
From: Sweet Tea Dorminy @ 2022-10-20 16:58 UTC (permalink / raw)
  To: Theodore Y. Ts'o, Jaegeuk Kim, Eric Biggers, Chris Mason,
	Josef Bacik, David Sterba, linux-fscrypt, linux-btrfs,
	kernel-team
  Cc: Sweet Tea Dorminy

This is a changeset adding encryption to btrfs.

Last October, Omar Sandoval 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. We have
refined this into a fscrypt extent context object, opaque to the
filesystem, which fscrypt uses to generate an IV associated with each
block in an extent. Thus, all the inodes sharing a particular
key and file extent may decrypt the extent.

This series implements this integration for the simple case,
non-compressed data extents, and for verity items. Followup changes will
allow encryption of compressed extents, inline extents, and will add
tests around subvolume encryption. This series should provide encryption
for the simplest cases, but this series should not be used in
production, as there are likely bugs.

This set hopefully reflects all of the feedback given on v2, with two
exceptions: per-extent keys, and fewer fscrypt extent context members of
btrfs structures.

On v2, Eric Biggers suggested in passing we reconsider having
per-extent keys, instead of continuing to rely on per-inode keys.
Previously, we'd considered this too memory expensive, as our reference
system averaged 4 extents per inode. But if we gave each extent its own
key structure, non-dir inodes would no longer need its own keys, making
up for the increased memory; and we can free and recreate keys as
needed to fit within a smaller memory space, it just results in more
churn. Additionally, there's a certain elegance potentially resulting:
we could take any number of levels of snapshot, giving each snapshot a
new key, and the last snapshot could be readable if you loaded all of
the N keys; this is more elegant than just supporting mixed single-key
and unencrypted extents. However, after giving this a lengthy try, I
found the result too ugly. There seemed just too many ifs in the fscrypt
hooks necessary to refer to the parent dir in many places if
extent-based, and it seemed too expensive and redundant to just have
full fscrypt contexts for both all inodes and all extents. So this
version still has only a fscrypt_iv in each fscrypt_extent_context. I
would love suggestions on how to elegantly implement per-extent keys;
the elegance of their theory is delightful.

Secondly, on v2 David Sterba disliked the abundant new fscrypt_context
members of multiple structures and hoped they could be smaller or less
frequent, and perhaps compiled out if CONFIG_FS_ENCRYPTION is disabled.
I didn't split the extent contexts out into separately allocated and
freed structures, and I preserved a 1-byte member even when encryption
is disabled in order to not ifdef every check for encryption. However,
if this turns out too inelegant, I'm happy to amend things further, or
separate the objects from extent maps altogether. My impression is that
most fscrypt functions have a no-encryption version which returns an
error, so their calls don't need to be gated on encryption.

I apologize if I missed any past feedback.

[1]
https://lore.kernel.org/linux-btrfs/YXGyq+buM79A1S0L@relinquished.localdomain/

Changelog:
v3: 
 - fscrypt: changed to generate extent contexts the same way as IVs are
   generated for inode-based encryption, allowing use of any existing
   policy and making the difference in encryption more minimal.
 - Changed to use qstr's, then fscrypt_strs, then fscrypt_names only
   where absolutely necessary, rather than fscrypt_names everywhere.
 - Reordered changes to put partially-encrypted directories, and no-key
   name handling, in their own sections at the end of the patchset.
 - Expanded on descriptions of how no-key name handling works.
 - Added encryption of verity items (but see notes in change about
   outstanding questions there)
 - Stylistic fixes
 - Renamed flags from FSCRYPT to ENCRYPT in multiple instances.
 - Made the incompat encrypt superblock flag be set the first time a
   directory is set to be encrypted, so there isn't a need for a mkfs
   option.
 - Hopefully addressed all other minor feedback points.

v2:
 - Amended the fscrypt side to generically add extent contexts,
   hopefully as per Eric Biggers' past comments. IVs are now entirely
   abstracted within an extent context, and there is no longer a new
   encryption policy, as DIRECT_KEY sufficiently encapsulates the
   needs of extent-based encryption. Documented its usage in btrfs
   briefly in the documentation. 
 - Adjusted the btrfs side to deal in opaque extent contexts. Improved
   optimization to skip storing inode contexts if they are the same as
   the inode's root item's inode context.
 - Combined 'add fscrypt operation table to superblock' into 'start
   using fscrypt hooks'.
 - https://lore.kernel.org/linux-btrfs/cover.1662420176.git.sweettea-kernel@dorminy.me
 - progs: https://lore.kernel.org/linux-btrfs/cover.1662417859.git.sweettea-kernel@dorminy.me
 - tests: https://lore.kernel.org/linux-btrfs/cover.1662417905.git.sweettea-kernel@dorminy.me

v1:
 - Recombined the fscrypt changes back into this patchset.
 - Fixed several races and incorrectly ordered operations.
 - Improved IV retrieval to correctly distinguish between
   filename/symlink encryption and encryption of block 0 of a file.
 - https://lore.kernel.org/linux-btrfs/cover.1660744500.git.sweettea-kernel@dorminy.me
 - progs: https://lore.kernel.org/linux-btrfs/cover.1660729916.git.sweettea-kernel@dorminy.me
 - tests: https://lore.kernel.org/linux-btrfs/cover.1660729861.git.sweettea-kernel@dorminy.me

RFC 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.
 - https://lore.kernel.org/linux-btrfs/cover.1658623319.git.sweettea-kernel@dorminy.me 

RFC v1:
 - https://lore.kernel.org/linux-btrfs/cover.1657707686.git.sweettea-kernel@dorminy.me


Omar Sandoval (12):
  fscrypt: expose fscrypt_nokey_name
  fscrypt: add fscrypt_have_same_policy() to check inode compatibility
  btrfs: store directory encryption state
  btrfs: disable various operations on encrypted inodes
  btrfs: start using fscrypt hooks
  btrfs: add fscrypt_context items
  btrfs: translate btrfs encryption flags and encrypted inode flag
  btrfs: encrypt normal file extent data if appropriate
  btrfs: Add new FEATURE_INCOMPAT_ENCRYPT feature flag.
  btrfs: implement fscrypt ioctls
  btrfs: permit searching for nokey names for removal
  fscrypt: add flag allowing partially-encrypted directories

Sweet Tea Dorminy (10):
  fscrypt: allow fscrypt_generate_iv() to distinguish filenames
  fscrypt: add extent-based encryption
  fscrypt: document btrfs' fscrypt quirks.
  btrfs: use struct qstr instead of name and namelen
  btrfs: setup qstrings from dentrys using fscrypt helper
  btrfs: use struct fscrypt_str instead of struct qstr
  btrfs: store a fscrypt extent context per normal file extent
  btrfs: use correct name hash for nokey names
  btrfs: adapt lookup for partially encrypted directories
  btrfs: encrypt verity items

 Documentation/filesystems/fscrypt.rst |  62 ++-
 fs/btrfs/Makefile                     |   1 +
 fs/btrfs/btrfs_inode.h                |   3 +
 fs/btrfs/ctree.h                      |  96 ++++-
 fs/btrfs/delayed-inode.c              |  36 +-
 fs/btrfs/delayed-inode.h              |   6 +-
 fs/btrfs/dir-item.c                   | 193 +++++++--
 fs/btrfs/extent_io.c                  |  94 ++++-
 fs/btrfs/extent_io.h                  |   3 +
 fs/btrfs/extent_map.c                 |   7 +
 fs/btrfs/extent_map.h                 |   4 +
 fs/btrfs/file-item.c                  |  25 +-
 fs/btrfs/file.c                       |  11 +-
 fs/btrfs/fscrypt.c                    | 273 +++++++++++++
 fs/btrfs/fscrypt.h                    |  63 +++
 fs/btrfs/inode-item.c                 |  73 ++--
 fs/btrfs/inode-item.h                 |  20 +-
 fs/btrfs/inode.c                      | 559 +++++++++++++++++++-------
 fs/btrfs/ioctl.c                      |  55 ++-
 fs/btrfs/ordered-data.c               |  11 +-
 fs/btrfs/ordered-data.h               |   4 +-
 fs/btrfs/print-tree.c                 |   4 +-
 fs/btrfs/reflink.c                    |   8 +
 fs/btrfs/root-tree.c                  |  21 +-
 fs/btrfs/send.c                       |  13 +-
 fs/btrfs/super.c                      |  10 +-
 fs/btrfs/transaction.c                |  40 +-
 fs/btrfs/tree-checker.c               |  51 ++-
 fs/btrfs/tree-log.c                   | 304 +++++++-------
 fs/btrfs/tree-log.h                   |   4 +-
 fs/btrfs/verity.c                     | 112 +++++-
 fs/crypto/crypto.c                    |  29 +-
 fs/crypto/fname.c                     |  60 +--
 fs/crypto/fscrypt_private.h           |  25 +-
 fs/crypto/inline_crypt.c              |  28 +-
 fs/crypto/policy.c                    | 105 +++++
 include/linux/fscrypt.h               |  93 +++++
 include/uapi/linux/btrfs.h            |   1 +
 include/uapi/linux/btrfs_tree.h       |  28 ++
 39 files changed, 1978 insertions(+), 557 deletions(-)
 create mode 100644 fs/btrfs/fscrypt.c
 create mode 100644 fs/btrfs/fscrypt.h

-- 
2.35.1


^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2022-10-21 20:58 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-20 16:58 [PATCH v3 00/22] btrfs: add fscrypt integration Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 01/22] fscrypt: expose fscrypt_nokey_name Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 02/22] fscrypt: add fscrypt_have_same_policy() to check inode compatibility Sweet Tea Dorminy
2022-10-20 20:52   ` Josef Bacik
2022-10-20 16:58 ` [PATCH v3 03/22] fscrypt: allow fscrypt_generate_iv() to distinguish filenames Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 04/22] fscrypt: add extent-based encryption Sweet Tea Dorminy
2022-10-20 21:40   ` Eric Biggers
2022-10-20 22:20     ` Sweet Tea Dorminy
2022-10-20 21:45   ` Eric Biggers
2022-10-20 22:55     ` Sweet Tea Dorminy
2022-10-20 23:56       ` Eric Biggers
2022-10-21  0:37         ` Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 05/22] fscrypt: document btrfs' fscrypt quirks Sweet Tea Dorminy
2022-10-20 21:41   ` Eric Biggers
2022-10-20 22:07     ` Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 06/22] btrfs: use struct qstr instead of name and namelen Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 07/22] btrfs: setup qstrings from dentrys using fscrypt helper Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 08/22] btrfs: use struct fscrypt_str instead of struct qstr Sweet Tea Dorminy
2022-10-21 20:42   ` Josef Bacik
2022-10-20 16:58 ` [PATCH v3 09/22] btrfs: store directory encryption state Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 10/22] btrfs: disable various operations on encrypted inodes Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 11/22] btrfs: start using fscrypt hooks Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 12/22] btrfs: add fscrypt_context items Sweet Tea Dorminy
2022-10-21 20:54   ` Josef Bacik
2022-10-20 16:58 ` [PATCH v3 13/22] btrfs: translate btrfs encryption flags and encrypted inode flag Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 14/22] btrfs: store a fscrypt extent context per normal file extent Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 15/22] btrfs: encrypt normal file extent data if appropriate Sweet Tea Dorminy
2022-10-21 20:58   ` Josef Bacik
2022-10-20 16:58 ` [PATCH v3 16/22] btrfs: Add new FEATURE_INCOMPAT_ENCRYPT feature flag Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 17/22] btrfs: implement fscrypt ioctls Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 18/22] btrfs: permit searching for nokey names for removal Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 19/22] btrfs: use correct name hash for nokey names Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 20/22] btrfs: adapt lookup for partially encrypted directories Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 21/22] fscrypt: add flag allowing partially-encrypted directories Sweet Tea Dorminy
2022-10-20 16:58 ` [PATCH v3 22/22] btrfs: encrypt verity items Sweet Tea Dorminy
2022-10-20 21:38 ` [PATCH v3 00/22] btrfs: add fscrypt integration Eric Biggers
2022-10-20 23:12   ` David Sterba

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