Linux block layer
 help / color / mirror / Atom feed
From: Daniel Vacek <neelx@suse.com>
To: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
	Eric Biggers <ebiggers@kernel.org>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	David Sterba <dsterba@suse.com>
Cc: linux-block@vger.kernel.org, Daniel Vacek <neelx@suse.com>,
	linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH v7 04/43] fscrypt: conditionally don't wipe mk secret until the last active user is done
Date: Wed, 13 May 2026 10:52:38 +0200	[thread overview]
Message-ID: <20260513085340.3673127-5-neelx@suse.com> (raw)
In-Reply-To: <20260513085340.3673127-1-neelx@suse.com>

From: Josef Bacik <josef@toxicpanda.com>

Previously we were wiping the master key secret when we do
FS_IOC_REMOVE_ENCRYPTION_KEY, and then using the fact that it was
cleared as the mechanism from keeping new users from being setup.  This
works with inode based encryption, as the per-inode key is derived at
setup time, so the secret disappearing doesn't affect any currently open
files from being able to continue working.

However for extent based encryption we do our key derivation at page
writeout and readpage time, which means we need the master key secret to
be available while we still have our file open.

Since the master key lifetime is controlled by a flag, move the clearing
of the secret to the mk_active_users cleanup stage if we have extent
based encryption enabled on this super block.  This counter represents
the actively open files that still exist on the file system, and thus
should still be able to operate normally.  Once the last user is closed
we can clear the secret.  Until then no new users are allowed, and this
allows currently open files to continue to operate until they're closed.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---

v7 changes:
 * Updated the comment about key status in fscrypt_master_key_secret structure
   as suggested by Eric.
No changes in v6.
v5: https://lore.kernel.org/linux-btrfs/5f28e46ce99d918a16f5bf4d8190870d0fffefc4.1706116485.git.josef@toxicpanda.com/
---
 fs/crypto/fscrypt_private.h |  9 ++++++---
 fs/crypto/keyring.c         | 18 +++++++++++++++++-
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/fs/crypto/fscrypt_private.h b/fs/crypto/fscrypt_private.h
index e5ab9893dfed..2f5f4e7f8f65 100644
--- a/fs/crypto/fscrypt_private.h
+++ b/fs/crypto/fscrypt_private.h
@@ -592,9 +592,12 @@ struct fscrypt_master_key_secret {
  *
  * FSCRYPT_KEY_STATUS_INCOMPLETELY_REMOVED
  *	Removal of this key has been initiated, but some inodes that were
- *	unlocked with it are still in-use.  Like ABSENT, ->mk_secret is wiped,
- *	and the key can no longer be used to unlock inodes.  Unlike ABSENT, the
- *	key is still in the keyring; ->mk_decrypted_inodes is nonempty; and
+ *	unlocked with it are still in-use.
+ *	For filesystems using per-extent encryption ->mk_secret is still
+ *	being kept as the per-extent keys are derived at writeout time.
+ *	Otherwise, like ABSENT, ->mk_secret is wiped, and the key can
+ *	no longer be used to unlock inodes.  Unlike ABSENT, the key is
+ *	still in the keyring; ->mk_decrypted_inodes is nonempty; and
  *	->mk_active_refs > 0, being equal to the size of ->mk_decrypted_inodes.
  *
  *	This state transitions to ABSENT if ->mk_decrypted_inodes becomes empty,
diff --git a/fs/crypto/keyring.c b/fs/crypto/keyring.c
index be8e6e8011f2..796e02a0db25 100644
--- a/fs/crypto/keyring.c
+++ b/fs/crypto/keyring.c
@@ -110,6 +110,14 @@ void fscrypt_put_master_key_activeref(struct super_block *sb,
 	WARN_ON_ONCE(mk->mk_present);
 	WARN_ON_ONCE(!list_empty(&mk->mk_decrypted_inodes));
 
+	/* We can't wipe the master key secret until the last activeref is
+	 * dropped on the master key with per-extent encryption since the key
+	 * derivation continues to happen as long as there are active refs.
+	 * Wipe it here now that we're done using it.
+	 */
+	if (sb->s_cop->has_per_extent_encryption)
+		wipe_master_key_secret(&mk->mk_secret);
+
 	for (i = 0; i <= FSCRYPT_MODE_MAX; i++) {
 		fscrypt_destroy_prepared_key(
 				sb, &mk->mk_direct_keys[i]);
@@ -134,7 +142,15 @@ static void fscrypt_initiate_key_removal(struct super_block *sb,
 					 struct fscrypt_master_key *mk)
 {
 	WRITE_ONCE(mk->mk_present, false);
-	wipe_master_key_secret(&mk->mk_secret);
+
+	/*
+	 * Per-extent encryption requires the master key to stick around until
+	 * writeout has completed as we derive the per-extent keys at writeout
+	 * time.  Once the activeref drops to 0 we'll wipe the master secret
+	 * key.
+	 */
+	if (!sb->s_cop->has_per_extent_encryption)
+		wipe_master_key_secret(&mk->mk_secret);
 	fscrypt_put_master_key_activeref(sb, mk);
 }
 
-- 
2.53.0


  parent reply	other threads:[~2026-05-13  8:54 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  8:52 [PATCH v7 00/43] btrfs: add fscrypt support Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 01/43] fscrypt: add per-extent encryption support Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 02/43] fscrypt: allow inline encryption for extent based encryption Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 03/43] fscrypt: add a __fscrypt_file_open helper Daniel Vacek
2026-05-13  8:52 ` Daniel Vacek [this message]
2026-05-13  8:52 ` [PATCH v7 05/43] blk-crypto: add a process bio callback Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 06/43] fscrypt: add a process_bio hook to fscrypt_operations Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 07/43] fscrypt: expose fscrypt_nokey_name Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 08/43] fscrypt: add documentation about extent encryption Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 09/43] btrfs: add infrastructure for safe em freeing Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 10/43] btrfs: start using fscrypt hooks Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 11/43] btrfs: add inode encryption contexts Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 12/43] btrfs: add new FEATURE_INCOMPAT_ENCRYPT flag Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 13/43] btrfs: adapt readdir for encrypted and nokey names Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 14/43] btrfs: handle " Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 15/43] btrfs: implement fscrypt ioctls Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 16/43] btrfs: select encryption dependencies if FS_ENCRYPTION Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 17/43] btrfs: add get_devices hook for fscrypt Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 18/43] btrfs: set file extent encryption excplicitly Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 19/43] btrfs: add fscrypt_info and encryption_type to extent_map Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 20/43] btrfs: add fscrypt_info and encryption_type to ordered_extent Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 21/43] btrfs: plumb through setting the fscrypt_info for ordered extents Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 22/43] btrfs: populate the ordered_extent with the fscrypt context Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 23/43] btrfs: keep track of fscrypt info and orig_start for dio reads Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 24/43] btrfs: add extent encryption context tree item type Daniel Vacek
2026-05-13  8:52 ` [PATCH v7 25/43] btrfs: pass through fscrypt_extent_info to the file extent helpers Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 26/43] btrfs: implement the fscrypt extent encryption hooks Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 27/43] btrfs: setup fscrypt_extent_info for new extents Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 28/43] btrfs: populate ordered_extent with the orig offset Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 29/43] btrfs: set the bio fscrypt context when applicable Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 30/43] btrfs: add a bio argument to btrfs_csum_one_bio Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 31/43] btrfs: limit encrypted writes to 256 segments Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 32/43] btrfs: implement process_bio cb for fscrypt Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 33/43] btrfs: implement read repair for encryption Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 34/43] btrfs: add test_dummy_encryption support Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 35/43] btrfs: make btrfs_ref_to_path handle encrypted filenames Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 36/43] btrfs: deal with encrypted symlinks in send Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 37/43] btrfs: decrypt file names for send Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 38/43] btrfs: load the inode context before sending writes Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 39/43] btrfs: set the appropriate free space settings in reconfigure Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 40/43] btrfs: support encryption with log replay Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 41/43] btrfs: disable auto defrag on encrypted files Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 42/43] btrfs: disable encryption on RAID5/6 Daniel Vacek
2026-05-13  8:53 ` [PATCH v7 43/43] btrfs: disable send if we have encryption enabled Daniel Vacek

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=20260513085340.3673127-5-neelx@suse.com \
    --to=neelx@suse.com \
    --cc=axboe@kernel.dk \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@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