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 v4 5/8] fscrypt: reduce special-casing of IV_INO_LBLK_32
Date: Wed, 28 Jun 2023 20:28:55 -0400 [thread overview]
Message-ID: <761a44f07219a83c7b5d30990922f07363a4e305.1687988119.git.sweettea-kernel@dorminy.me> (raw)
In-Reply-To: <cover.1687988119.git.sweettea-kernel@dorminy.me>
Right now, the IV_INO_LBLK_32 policy is handled by its own function
called in fscrypt_setup_v2_file_key(), different from all other policies
which just call find_mode_prepared_key() with various parameters. The
function additionally sets up the relevant inode hashing key in the
master key, and uses it to hash the inode number if possible. This is
not particularly relevant to setting up a prepared key, so this change
tries to make it clear that every non-default policy uses basically the
same setup mechanism for its prepared key. The other setup is moved to
be called from the top crypt_info setup function.
Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
---
fs/crypto/keysetup.c | 62 +++++++++++++++++++++++---------------------
1 file changed, 32 insertions(+), 30 deletions(-)
diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
index 302a1ccde439..0648ae22ecc4 100644
--- a/fs/crypto/keysetup.c
+++ b/fs/crypto/keysetup.c
@@ -302,44 +302,30 @@ void fscrypt_hash_inode_number(struct fscrypt_info *ci,
&mk->mk_ino_hash_key);
}
-static int fscrypt_setup_iv_ino_lblk_32_key(struct fscrypt_info *ci,
- struct fscrypt_master_key *mk)
+static int fscrypt_setup_ino_hash_key(struct fscrypt_master_key *mk)
{
int err;
- err = find_mode_prepared_key(ci, mk, mk->mk_iv_ino_lblk_32_keys,
- HKDF_CONTEXT_IV_INO_LBLK_32_KEY, true);
- if (err)
- return err;
-
/* pairs with smp_store_release() below */
- if (!smp_load_acquire(&mk->mk_ino_hash_key_initialized)) {
+ if (smp_load_acquire(&mk->mk_ino_hash_key_initialized))
+ return 0;
- mutex_lock(&fscrypt_mode_key_setup_mutex);
+ mutex_lock(&fscrypt_mode_key_setup_mutex);
- if (mk->mk_ino_hash_key_initialized)
- goto unlock;
+ if (mk->mk_ino_hash_key_initialized)
+ goto unlock;
- err = fscrypt_derive_siphash_key(mk,
- HKDF_CONTEXT_INODE_HASH_KEY,
- NULL, 0, &mk->mk_ino_hash_key);
- if (err)
- goto unlock;
- /* pairs with smp_load_acquire() above */
- smp_store_release(&mk->mk_ino_hash_key_initialized, true);
+ err = fscrypt_derive_siphash_key(mk,
+ HKDF_CONTEXT_INODE_HASH_KEY,
+ NULL, 0, &mk->mk_ino_hash_key);
+ if (err)
+ goto unlock;
+ /* pairs with smp_load_acquire() above */
+ smp_store_release(&mk->mk_ino_hash_key_initialized, true);
unlock:
- mutex_unlock(&fscrypt_mode_key_setup_mutex);
- if (err)
- return err;
- }
+ mutex_unlock(&fscrypt_mode_key_setup_mutex);
- /*
- * New inodes may not have an inode number assigned yet.
- * Hashing their inode number is delayed until later.
- */
- if (ci->ci_inode->i_ino)
- fscrypt_hash_inode_number(ci, mk);
- return 0;
+ return err;
}
static int fscrypt_setup_v2_file_key(struct fscrypt_info *ci,
@@ -371,7 +357,9 @@ static int fscrypt_setup_v2_file_key(struct fscrypt_info *ci,
true);
} else if (ci->ci_policy.v2.flags &
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32) {
- err = fscrypt_setup_iv_ino_lblk_32_key(ci, mk);
+ err = find_mode_prepared_key(ci, mk, mk->mk_iv_ino_lblk_32_keys,
+ HKDF_CONTEXT_IV_INO_LBLK_32_KEY,
+ true);
} else {
u8 derived_key[FSCRYPT_MAX_KEY_SIZE];
@@ -629,6 +617,20 @@ fscrypt_setup_encryption_info(struct inode *inode,
goto out;
}
+ /*
+ * The IV_INO_LBLK_32 policy needs a hashed inode number, but new
+ * inodes may not have an inode number assigned yet.
+ */
+ if (policy->version == FSCRYPT_POLICY_V2 &&
+ (policy->v2.flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32)) {
+ res = fscrypt_setup_ino_hash_key(mk);
+ if (res)
+ goto out;
+
+ if (inode->i_ino)
+ fscrypt_hash_inode_number(crypt_info, mk);
+ }
+
/*
* 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.1
next prev parent reply other threads:[~2023-06-29 0:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 0:28 [PATCH v4 0/8] fscrypt: some rearrangements of key setup Sweet Tea Dorminy
2023-06-29 0:28 ` [PATCH v4 1/8] fscrypt: move inline crypt decision to info setup Sweet Tea Dorminy
2023-06-29 0:28 ` [PATCH v4 2/8] fscrypt: split and rename setup_file_encryption_key() Sweet Tea Dorminy
2023-06-29 0:28 ` [PATCH v4 3/8] fscrypt: split setup_per_mode_enc_key() Sweet Tea Dorminy
2023-06-29 2:44 ` kernel test robot
2023-06-29 0:28 ` [PATCH v4 4/8] fscrypt: move dirhash key setup away from IO key setup Sweet Tea Dorminy
2023-06-29 0:28 ` Sweet Tea Dorminy [this message]
2023-06-29 0:28 ` [PATCH v4 6/8] fscrypt: move all the shared mode key setup deeper Sweet Tea Dorminy
2023-06-29 0:28 ` [PATCH v4 7/8] fscrypt: make infos have a pointer to prepared keys Sweet Tea Dorminy
2023-06-29 0:28 ` [PATCH v4 8/8] fscrypt: make prepared keys record their type 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=761a44f07219a83c7b5d30990922f07363a4e305.1687988119.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).