From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
Eric Biggers <ebiggers@kernel.org>,
"Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
kernel-team@meta.com, linux-btrfs@vger.kernel.org,
linux-fscrypt@vger.kernel.org
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: [PATCH v1 00/12] fscrypt: add extent encryption
Date: Wed, 28 Jun 2023 20:29:30 -0400 [thread overview]
Message-ID: <cover.1687988246.git.sweettea-kernel@dorminy.me> (raw)
This changeset adds extent-based data encryption to fscrypt.
Some filesystems need to encrypt data based on extents, rather than on
inodes, due to features incompatible with inode-based encryption. For
instance, btrfs can have multiple inodes referencing a single block of
data, and moves logical data blocks to different physical locations on
disk in the background.
As per discussion last year in [1] and later in [2], we would like to
allow the use of fscrypt with btrfs, with authenticated encryption. This
is the first step of that work, adding extent-based encryption to
fscrypt; authenticated encryption is the next step. Extent-based
encryption should be usable by other filesystems which wish to support
snapshotting or background data rearrangement also, but btrfs is the
first user.
This changeset requires extent encryption to use inlinecrypt, as
discussed previously. There are two questionable parts: the
forget_extent_info hook is not yet in use by btrfs, as I haven't yet
written a test exercising a race where it would be relevant; and saving
the session key credentials just to enable v1 session-based policies is
perhaps less good than
This applies atop [3], which itself is based on kdave/misc-next. It
passes most encryption fstests with suitable changes to btrfs-progs, but
not generic/580 or generic/595 due to different timing involved in
extent encryption. Tests and btrfs progs updates to follow.
[1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing
[2] https://lore.kernel.org/linux-fscrypt/80496cfe-161d-fb0d-8230-93818b966b1b@dorminy.me/T/#t
[3]
https://lore.kernel.org/linux-fscrypt/cover.1687988119.git.sweettea-kernel@dorminy.me/
Sweet Tea Dorminy (12):
fscrypt: factor helper for locking master key
fscrypt: factor getting info for a specific block
fscrypt: adjust effective lblks based on extents
fscrypt: add a super_block pointer to fscrypt_info
fscrypt: setup leaf inodes for extent encryption
fscrypt: allow infos to be owned by extents
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: save session key credentials for extent infos
fscrypt: update documentation for per-extent keys
Documentation/filesystems/fscrypt.rst | 38 +++-
fs/crypto/crypto.c | 6 +-
fs/crypto/fscrypt_private.h | 91 ++++++++++
fs/crypto/inline_crypt.c | 28 ++-
fs/crypto/keyring.c | 32 +++-
fs/crypto/keysetup.c | 244 ++++++++++++++++++++++----
fs/crypto/keysetup_v1.c | 7 +-
fs/crypto/policy.c | 20 +++
include/linux/fscrypt.h | 74 ++++++++
9 files changed, 480 insertions(+), 60 deletions(-)
base-commit: accadeb67609a5a5d088ebde8409c3f6db0b84b4
--
2.40.1
next reply other threads:[~2023-06-29 0:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 0:29 Sweet Tea Dorminy [this message]
2023-06-29 0:29 ` [PATCH v1 01/12] fscrypt: factor helper for locking master key Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 02/12] fscrypt: factor getting info for a specific block Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 03/12] fscrypt: adjust effective lblks based on extents Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 04/12] fscrypt: add a super_block pointer to fscrypt_info Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 05/12] fscrypt: setup leaf inodes for extent encryption Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 06/12] fscrypt: allow infos to be owned by extents Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 07/12] fscrypt: notify per-extent infos if master key vanishes Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 08/12] fscrypt: use an optional ino equivalent for per-extent infos Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 09/12] fscrypt: add creation/usage/freeing of " Sweet Tea Dorminy
2023-06-29 1:55 ` Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 10/12] fscrypt: allow load/save of extent contexts Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 11/12] fscrypt: save session key credentials for extent infos Sweet Tea Dorminy
2023-06-29 0:29 ` [PATCH v1 12/12] fscrypt: update documentation for per-extent keys Sweet Tea Dorminy
2023-07-03 4:54 ` [PATCH v1 00/12] fscrypt: add extent encryption Eric Biggers
2023-07-03 17:06 ` Sweet Tea Dorminy
2023-07-03 18:17 ` Eric Biggers
2023-07-03 20:37 ` Sweet Tea Dorminy
2023-07-04 0:28 ` Eric Biggers
2023-07-04 1:57 ` Sweet Tea Dorminy
2023-07-05 12:13 ` Neal Gompa
2023-07-05 16:28 ` Eric Biggers
2023-07-05 17:00 ` Sweet Tea Dorminy
2023-07-05 19:41 ` 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.1687988246.git.sweettea-kernel@dorminy.me \
--to=sweettea-kernel@dorminy.me \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=tytso@mit.edu \
/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