All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: linux-fscrypt@vger.kernel.org, ebiggers@kernel.org,
	paulcrowley@google.com, linux-btrfs@vger.kernel.org,
	kernel-team@meta.com
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: [RFC PATCH 00/17] fscrypt: add per-extent encryption keys
Date: Sun,  1 Jan 2023 00:06:04 -0500	[thread overview]
Message-ID: <cover.1672547582.git.sweettea-kernel@dorminy.me> (raw)

Last month, after a discussion of using fscrypt in btrfs, several
potential areas for expansion of fscrypt functionality were identified:
specifically, per-extent keys, authenticated encryption, and 'rekeying'
a directory tree [1]. These additions will permit btrfs to have better
cryptographic characteristics than previous attempts at expanding btrfs
to use fscrypt.

This attempts to implement the first of these, per-extent keys (in
analogy to the current per-inode keys) in fscrypt. For a filesystem
using per-extent keys, the idea is that each regular file inode is
linked to its parent directory's fscrypt_info, while each extent in
the filesystem -- opaque to fscrypt -- stores a fscrypt_info providing
the key for the data in that extent. For non-regular files, the inode
has its own fscrypt_info as in current ("inode-based") fscrypt.  

IV generation methods using logical block numbers use the logical block
number within the extent, and for IV generation methods using inode
numbers, such filesystems may optionally implement a method providing an
equivalent on a per-extent basis. 

Known limitations: change 12 ("fscrypt: notify per-extent infos if
master key vanishes") does not sufficiently argue that there cannot be a
race between freeing a master key and using it for some pending extent IO.
Change 16 ("fscrypt: disable inline encryption for extent-based
encryption") merely disables inline encryption, when it should implement
generating appropriate inline encryption info for extent infos.

This has not been thoroughly tested against a btrfs implementation of
the interfaces -- I've thrown out everything here and tried something
new several times, and while I think this interface is a decent one, I
would like to get input on it in parallel with finishing the btrfs side
of this part, and the other elements of the design mentioned in [1]

[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing

*** BLURB HERE ***

Sweet Tea Dorminy (17):
  fscrypt: factor accessing inode->i_crypt_info
  fscrypt: separate getting info for a specific block
  fscrypt: adjust effective lblks based on extents
  fscrypt: factor out fscrypt_set_inode_info()
  fscrypt: use parent dir's info for extent-based encryption.
  fscrypt: add a super_block pointer to fscrypt_info
  fscrypt: update comments about inodes to include extents
  fscrypt: rename mk->mk_decrypted_inodes*
  fscrypt: make fscrypt_setup_encryption_info generic for extents
  fscrypt: let fscrypt_infos be owned by an extent
  fscrypt: update all the *per_file_* function names
  fscrypt: notify per-extent infos if master key vanishes
  fscrypt: use an optional ino equivalent for per-extent infos
  fscrypt: add creation/usage/freeing of per-extent infos
  fscrypt: allow load/save of extent contexts
  fscrypt: disable inline encryption for extent-based encryption
  fscrypt: update documentation to mention per-extent keys.

 Documentation/filesystems/fscrypt.rst |  38 +++-
 fs/crypto/crypto.c                    |  17 +-
 fs/crypto/fname.c                     |   9 +-
 fs/crypto/fscrypt_private.h           | 174 +++++++++++++----
 fs/crypto/hooks.c                     |   2 +-
 fs/crypto/inline_crypt.c              |  42 ++--
 fs/crypto/keyring.c                   |  67 ++++---
 fs/crypto/keysetup.c                  | 263 ++++++++++++++++++++------
 fs/crypto/keysetup_v1.c               |  24 +--
 fs/crypto/policy.c                    |  28 ++-
 include/linux/fscrypt.h               |  76 ++++++++
 11 files changed, 580 insertions(+), 160 deletions(-)


base-commit: b7af0635c87ff78d6bd523298ab7471f9ffd3ce5
-- 
2.38.1


             reply	other threads:[~2023-01-01  5:06 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-01  5:06 Sweet Tea Dorminy [this message]
2023-01-01  5:06 ` [RFC PATCH 01/17] fscrypt: factor accessing inode->i_crypt_info Sweet Tea Dorminy
2023-01-02 21:00   ` Eric Biggers
2023-01-01  5:06 ` [RFC PATCH 02/17] fscrypt: separate getting info for a specific block Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 03/17] fscrypt: adjust effective lblks based on extents Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 04/17] fscrypt: factor out fscrypt_set_inode_info() Sweet Tea Dorminy
2023-01-01  6:03   ` kernel test robot
2023-01-01  6:13   ` kernel test robot
2023-01-01  5:06 ` [RFC PATCH 05/17] fscrypt: use parent dir's info for extent-based encryption Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 06/17] fscrypt: add a super_block pointer to fscrypt_info Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 07/17] fscrypt: update comments about inodes to include extents Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 08/17] fscrypt: rename mk->mk_decrypted_inodes* Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 09/17] fscrypt: make fscrypt_setup_encryption_info generic for extents Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 10/17] fscrypt: let fscrypt_infos be owned by an extent Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 11/17] fscrypt: update all the *per_file_* function names Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 12/17] fscrypt: notify per-extent infos if master key vanishes Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 13/17] fscrypt: use an optional ino equivalent for per-extent infos Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 14/17] fscrypt: add creation/usage/freeing of " Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 15/17] fscrypt: allow load/save of extent contexts Sweet Tea Dorminy
2023-01-01  6:33   ` kernel test robot
2023-01-02 21:47   ` Eric Biggers
2023-01-02 22:31     ` Sweet Tea Dorminy
2023-01-02 22:51       ` Eric Biggers
2023-01-03  0:33         ` Sweet Tea Dorminy
2023-01-03  0:47           ` Eric Biggers
2023-01-03  1:23             ` Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 16/17] fscrypt: disable inline encryption for extent-based encryption Sweet Tea Dorminy
2023-01-01  5:06 ` [RFC PATCH 17/17] fscrypt: update documentation to mention per-extent keys Sweet Tea Dorminy
2023-02-22 11:52 ` [RFC PATCH 00/17] fscrypt: add per-extent encryption keys Neal Gompa
2023-02-22 14:13   ` Sweet Tea Dorminy
2023-02-22 20:53     ` Eric Biggers
  -- strict thread matches above, loose matches on Subject: below --
2023-01-03 14:38 [RFC PATCH 04/17] fscrypt: factor out fscrypt_set_inode_info() kernel test robot
2023-01-04  8:37 ` Dan Carpenter
2023-01-03 15:28 [RFC PATCH 14/17] fscrypt: add creation/usage/freeing of per-extent infos kernel test robot
2023-01-04  8:41 ` Dan Carpenter
2023-01-03 16:19 [RFC PATCH 15/17] fscrypt: allow load/save of extent contexts kernel test robot
2023-01-04  8:42 ` Dan Carpenter

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.1672547582.git.sweettea-kernel@dorminy.me \
    --to=sweettea-kernel@dorminy.me \
    --cc=ebiggers@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=paulcrowley@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.