diff mbox series

ext4: make test_dummy_encryption require the encrypt feature

Message ID 20220421184040.173802-1-ebiggers@kernel.org (mailing list archive)
State New, archived
Headers show
Series ext4: make test_dummy_encryption require the encrypt feature | expand

Commit Message

Eric Biggers April 21, 2022, 6:40 p.m. UTC
From: Eric Biggers <ebiggers@google.com>

Make the test_dummy_encryption mount option require that the encrypt
feature flag be already enabled on the filesystem, rather than
automatically enabling it.  Practically, this means that "-O encrypt"
will need to be included in MKFS_OPTIONS when running xfstests with the
test_dummy_encryption mount option.

The motivation for this is that:

- Having the filesystem auto-enable feature flags is problematic, as it
  bypasses the usual sanity checks.  The specific issue which came up
  recently is that in kernel versions where ext4 supports casefold but
  not encrypt+casefold (v5.1 through v5.10), the kernel will happily add
  the encrypt flag to a filesystem that has the casefold flag, making it
  unmountable -- but only for subsequent mounts, not the initial one.
  This confused the casefold support detection in xfstests, causing
  generic/556 to fail rather than be skipped.

- The xfstests-bld test runners (kvm-xfstests et al.) already use the
  required mkfs flag, so they will not be affected by this change.  Only
  users of test_dummy_encryption alone will be affected.  But, this
  option has always been for testing only, so it should be fine to
  require that the few users of this option update their test scripts.

- f2fs already requires this.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 fs/ext4/super.c | 35 ++++++++++++++++++-----------------
 1 file changed, 18 insertions(+), 17 deletions(-)


base-commit: b2d229d4ddb17db541098b83524d901257e93845

Comments

Theodore Ts'o April 27, 2022, 3:24 p.m. UTC | #1
On Thu, Apr 21, 2022 at 11:40:40AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Make the test_dummy_encryption mount option require that the encrypt
> feature flag be already enabled on the filesystem, rather than
> automatically enabling it.  Practically, this means that "-O encrypt"
> will need to be included in MKFS_OPTIONS when running xfstests with the
> test_dummy_encryption mount option.
> 
> The motivation for this is that:
> 
> - Having the filesystem auto-enable feature flags is problematic, as it
>   bypasses the usual sanity checks.  The specific issue which came up
>   recently is that in kernel versions where ext4 supports casefold but
>   not encrypt+casefold (v5.1 through v5.10), the kernel will happily add
>   the encrypt flag to a filesystem that has the casefold flag, making it
>   unmountable -- but only for subsequent mounts, not the initial one.
>   This confused the casefold support detection in xfstests, causing
>   generic/556 to fail rather than be skipped.
> 
> - The xfstests-bld test runners (kvm-xfstests et al.) already use the
>   required mkfs flag, so they will not be affected by this change.  Only
>   users of test_dummy_encryption alone will be affected.  But, this
>   option has always been for testing only, so it should be fine to
>   require that the few users of this option update their test scripts.

One of the test scripts involved is xfstests's ext4/053, as the
zero-day test rebot has remarked upon.  Eric, could you look into
submitting a patch to xfstests's ext4/053.

Thanks!

					- Ted
diff mbox series

Patch

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 81749eaddf4c1..420eb29183eb4 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -2817,17 +2817,24 @@  static int ext4_check_opt_consistency(struct fs_context *fc,
 	}
 
 #ifdef CONFIG_FS_ENCRYPTION
-	/*
-	 * This mount option is just for testing, and it's not worthwhile to
-	 * implement the extra complexity (e.g. RCU protection) that would be
-	 * needed to allow it to be set or changed during remount.  We do allow
-	 * it to be specified during remount, but only if there is no change.
-	 */
-	if ((ctx->spec & EXT4_SPEC_DUMMY_ENCRYPTION) &&
-	    is_remount && !sbi->s_dummy_enc_policy.policy) {
-		ext4_msg(NULL, KERN_WARNING,
-			 "Can't set test_dummy_encryption on remount");
-		return -1;
+	if (ctx->spec & EXT4_SPEC_DUMMY_ENCRYPTION) {
+		if (!ext4_has_feature_encrypt(sb)) {
+			ext4_msg(NULL, KERN_WARNING,
+				 "test_dummy_encryption requires encrypt feature");
+			return -EINVAL;
+		}
+		/*
+		 * This mount option is just for testing, and it's not
+		 * worthwhile to implement the extra complexity (e.g. RCU
+		 * protection) that would be needed to allow it to be set or
+		 * changed during remount.  We do allow it to be specified
+		 * during remount, but only if there is no change.
+		 */
+		if (is_remount && !sbi->s_dummy_enc_policy.policy) {
+			ext4_msg(NULL, KERN_WARNING,
+				 "Can't set test_dummy_encryption on remount");
+			return -1;
+		}
 	}
 #endif
 
@@ -5272,12 +5279,6 @@  static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
 		goto failed_mount_wq;
 	}
 
-	if (DUMMY_ENCRYPTION_ENABLED(sbi) && !sb_rdonly(sb) &&
-	    !ext4_has_feature_encrypt(sb)) {
-		ext4_set_feature_encrypt(sb);
-		ext4_commit_super(sb);
-	}
-
 	/*
 	 * Get the # of file system overhead blocks from the
 	 * superblock if present.