All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
To: Eric Biggers <ebiggers@kernel.org>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-fscrypt@vger.kernel.org, kernel-team@meta.com
Cc: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: [PATCH v3 04/11] fscrypt: move dirhash key setup away from IO key setup
Date: Tue, 18 Apr 2023 13:04:41 -0400	[thread overview]
Message-ID: <0d3ae92ef973edcd70f18aa408de61e44dd7e28f.1681837335.git.sweettea-kernel@dorminy.me> (raw)
In-Reply-To: <cover.1681837335.git.sweettea-kernel@dorminy.me>

The function named fscrypt_setup_v2_file_key() has as its main focus the
setting up of the fscrypt_info's ci_enc_key member, the prepared key
with which filenames or file contents are encrypted or decrypted.
However, it currently also sets up the dirhash key, used by some
directories, based on a parameter. There are no dependencies on
setting up the dirhash key beyond having the master key locked, and it's
clearer having fscrypt_setup_file_key() be only about setting up the
prepared key for IO.

Thus, move dirhash key setup to fscrypt_setup_encryption_info(), which
calls out to each function setting up parts of the fscrypt_info, and
stop passing the need_dirhash_key parameter around.

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
---
 fs/crypto/keysetup.c | 37 +++++++++++++++++++++----------------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
index 69bd27b7e9d8..302a1ccde439 100644
--- a/fs/crypto/keysetup.c
+++ b/fs/crypto/keysetup.c
@@ -343,8 +343,7 @@ static int fscrypt_setup_iv_ino_lblk_32_key(struct fscrypt_info *ci,
 }
 
 static int fscrypt_setup_v2_file_key(struct fscrypt_info *ci,
-				     struct fscrypt_master_key *mk,
-				     bool need_dirhash_key)
+				     struct fscrypt_master_key *mk)
 {
 	int err;
 
@@ -386,25 +385,15 @@ static int fscrypt_setup_v2_file_key(struct fscrypt_info *ci,
 		err = fscrypt_set_per_file_enc_key(ci, derived_key);
 		memzero_explicit(derived_key, ci->ci_mode->keysize);
 	}
-	if (err)
-		return err;
 
-	/* Derive a secret dirhash key for directories that need it. */
-	if (need_dirhash_key) {
-		err = fscrypt_derive_dirhash_key(ci, mk);
-		if (err)
-			return err;
-	}
-
-	return 0;
+	return err;
 }
 
 /*
  * Find or create the appropriate prepared key for an info.
  */
 static int fscrypt_setup_file_key(struct fscrypt_info *ci,
-				  struct fscrypt_master_key *mk,
-				  bool need_dirhash_key)
+				  struct fscrypt_master_key *mk)
 {
 	int err;
 
@@ -426,7 +415,7 @@ static int fscrypt_setup_file_key(struct fscrypt_info *ci,
 		err = fscrypt_setup_v1_file_key(ci, mk->mk_secret.raw);
 		break;
 	case FSCRYPT_POLICY_V2:
-		err = fscrypt_setup_v2_file_key(ci, mk, need_dirhash_key);
+		err = fscrypt_setup_v2_file_key(ci, mk);
 		break;
 	default:
 		WARN_ON_ONCE(1);
@@ -620,10 +609,26 @@ fscrypt_setup_encryption_info(struct inode *inode,
 	if (res)
 		goto out;
 
-	res = fscrypt_setup_file_key(crypt_info, mk, need_dirhash_key);
+	res = fscrypt_setup_file_key(crypt_info, mk);
 	if (res)
 		goto out;
 
+	/*
+	 * Derive a secret dirhash key for directories that need it. It
+	 * should be impossible to set flags such that a v1 policy sets
+	 * need_dirhash_key, but check it anyway.
+	 */
+	if (need_dirhash_key) {
+		if (WARN_ON_ONCE(policy->version == FSCRYPT_POLICY_V1)) {
+			res = -EINVAL;
+			goto out;
+		}
+
+		res = fscrypt_derive_dirhash_key(crypt_info, mk);
+		if (res)
+			goto out;
+	}
+
 	/*
 	 * For existing inodes, multiple tasks may race to set ->i_crypt_info.
 	 * So use cmpxchg_release().  This pairs with the smp_load_acquire() in
-- 
2.40.0


  parent reply	other threads:[~2023-04-18 17:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 17:04 [PATCH 01/11] fscrypt: move inline crypt decision to info setup Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 02/11] fscrypt: split and rename setup_file_encryption_key() Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 03/11] fscrypt: split setup_per_mode_enc_key() Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 04/11] fscrypt: move dirhash key setup away from IO key setup Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 05/11] fscrypt: reduce special-casing of IV_INO_LBLK_32 Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 06/11] fscrypt: make infos have a pointer to prepared keys Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 07/11] fscrypt: move all the shared mode key setup deeper Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 08/11] fscrypt: make prepared keys record their type Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 09/11] fscrypt: lock every time a info needs a mode key Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 10/11] fscrypt: split key alloc and preparation Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH 11/11] fscrypt: factor helper for locking master key Sweet Tea Dorminy
2023-04-18 17:04 ` [PATCH v3 00/11] fscrypt: rearrangements preliminary to extent encryption Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 01/11] fscrypt: move inline crypt decision to info setup Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 02/11] fscrypt: split and rename setup_file_encryption_key() Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 03/11] fscrypt: split setup_per_mode_enc_key() Sweet Tea Dorminy
2023-04-18 17:04   ` Sweet Tea Dorminy [this message]
2023-04-18 17:04   ` [PATCH v3 05/11] fscrypt: reduce special-casing of IV_INO_LBLK_32 Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 06/11] fscrypt: make infos have a pointer to prepared keys Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 07/11] fscrypt: move all the shared mode key setup deeper Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 08/11] fscrypt: make prepared keys record their type Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 09/11] fscrypt: lock every time a info needs a mode key Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 10/11] fscrypt: split key alloc and preparation Sweet Tea Dorminy
2023-04-18 17:04   ` [PATCH v3 11/11] fscrypt: factor helper for locking master key 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=0d3ae92ef973edcd70f18aa408de61e44dd7e28f.1681837335.git.sweettea-kernel@dorminy.me \
    --to=sweettea-kernel@dorminy.me \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@meta.com \
    --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 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.