All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
	"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, Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH v6 2/8] fscrypt: split and rename setup_file_encryption_key()
Date: Wed, 9 Aug 2023 13:19:03 -0400	[thread overview]
Message-ID: <20230809171903.GA2516732@perftesting> (raw)
In-Reply-To: <5d9a09398c5432545db73d8f91d6b63cbfd0ee6f.1691505830.git.sweettea-kernel@dorminy.me>

On Tue, Aug 08, 2023 at 01:08:02PM -0400, Sweet Tea Dorminy wrote:
> At present, setup_file_encryption_key() does several things: it finds
> and locks the master key, and then calls into the appropriate functions
> to setup the prepared key for the fscrypt_info. The code is clearer to
> follow if these functions are divided.
> 
> Thus, move calling the appropriate file key setup function into a new
> fscrypt_setup_file_key() function. After the file key setup functions
> are moved, the remaining function can take a const fscrypt_info, and is
> renamed find_and_lock_master_key() to precisely describe its action.
> 
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> ---
>  fs/crypto/keysetup.c | 77 ++++++++++++++++++++++++++++++--------------
>  1 file changed, 52 insertions(+), 25 deletions(-)
> 
> diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c
> index b89c32ad19fb..727d473b6b03 100644
> --- a/fs/crypto/keysetup.c
> +++ b/fs/crypto/keysetup.c
> @@ -386,6 +386,43 @@ static int fscrypt_setup_v2_file_key(struct fscrypt_info *ci,
>  	return 0;
>  }
>  
> +/*
> + * 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)
> +{
> +	int err;
> +
> +	if (!mk) {
> +		if (ci->ci_policy.version != FSCRYPT_POLICY_V1)
> +			return -ENOKEY;
> +
> +		/*
> +		 * As a legacy fallback for v1 policies, search for the key in
> +		 * the current task's subscribed keyrings too.  Don't move this
> +		 * to before the search of ->s_master_keys, since users
> +		 * shouldn't be able to override filesystem-level keys.
> +		 */
> +		return fscrypt_setup_v1_file_key_via_subscribed_keyrings(ci);
> +	}
> +
> +	switch (ci->ci_policy.version) {
> +	case FSCRYPT_POLICY_V1:
> +		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);
> +		break;
> +	default:
> +		WARN_ON_ONCE(1);
> +		err = -EINVAL;
> +		break;
> +	}
> +	return err;
> +}
> +
>  /*
>   * Check whether the size of the given master key (@mk) is appropriate for the
>   * encryption settings which a particular file will use (@ci).
> @@ -426,7 +463,7 @@ static bool fscrypt_valid_master_key_size(const struct fscrypt_master_key *mk,
>  }
>  
>  /*
> - * Find the master key, then set up the inode's actual encryption key.
> + * Find and lock the master key.
>   *
>   * If the master key is found in the filesystem-level keyring, then it is
>   * returned in *mk_ret with its semaphore read-locked.  This is needed to ensure
> @@ -434,9 +471,8 @@ static bool fscrypt_valid_master_key_size(const struct fscrypt_master_key *mk,
>   * multiple tasks may race to create an fscrypt_info for the same inode), and to
>   * synchronize the master key being removed with a new inode starting to use it.
>   */
> -static int setup_file_encryption_key(struct fscrypt_info *ci,
> -				     bool need_dirhash_key,
> -				     struct fscrypt_master_key **mk_ret)
> +static int find_and_lock_master_key(const struct fscrypt_info *ci,
> +				    struct fscrypt_master_key **mk_ret)
>  {
>  	struct super_block *sb = ci->ci_inode->i_sb;
>  	struct fscrypt_key_specifier mk_spec;
> @@ -466,17 +502,19 @@ static int setup_file_encryption_key(struct fscrypt_info *ci,
>  			mk = fscrypt_find_master_key(sb, &mk_spec);
>  		}
>  	}
> +

Random newline, you can add

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

once you fix it up.  Thanks,

Josef

  reply	other threads:[~2023-08-09 17:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-08 17:08 [PATCH v6 0/8] fscrypt: preliminary rearrangmeents of key setup Sweet Tea Dorminy
2023-08-08 17:08 ` [PATCH v6 1/8] fscrypt: move inline crypt decision to info setup Sweet Tea Dorminy
2023-08-09 17:19   ` Josef Bacik
2023-08-08 17:08 ` [PATCH v6 2/8] fscrypt: split and rename setup_file_encryption_key() Sweet Tea Dorminy
2023-08-09 17:19   ` Josef Bacik [this message]
2023-08-10  6:34   ` Eric Biggers
2023-08-08 17:08 ` [PATCH v6 3/8] fscrypt: split setup_per_mode_enc_key() Sweet Tea Dorminy
2023-08-09 17:22   ` Josef Bacik
2023-08-10  6:37   ` Eric Biggers
2023-08-08 17:08 ` [PATCH v6 4/8] fscrypt: move dirhash key setup away from IO key setup Sweet Tea Dorminy
2023-08-09 17:25   ` Josef Bacik
2023-08-08 17:08 ` [PATCH v6 5/8] fscrypt: reduce special-casing of IV_INO_LBLK_32 Sweet Tea Dorminy
2023-08-09  5:30   ` kernel test robot
2023-08-10  6:57   ` Eric Biggers
2023-08-08 17:08 ` [PATCH v6 6/8] fscrypt: move all the shared mode key setup deeper Sweet Tea Dorminy
2023-08-09 17:40   ` Josef Bacik
2023-08-10  7:03   ` Eric Biggers
2023-08-08 17:08 ` [PATCH v6 7/8] fscrypt: make infos have a pointer to prepared keys Sweet Tea Dorminy
2023-08-09 17:42   ` Josef Bacik
2023-08-08 17:08 ` [PATCH v6 8/8] fscrypt: make prepared keys record their type Sweet Tea Dorminy
2023-08-09 17:44   ` Josef Bacik
2023-08-10  4:54   ` Dan Carpenter
2023-08-10  7:19   ` Eric Biggers

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=20230809171903.GA2516732@perftesting \
    --to=josef@toxicpanda.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=sweettea-kernel@dorminy.me \
    --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.