All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	linux-fscrypt@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v2 07/11] fscrypt: move all the shared mode key setup deeper
Date: Mon, 10 Apr 2023 20:56:04 -0700	[thread overview]
Message-ID: <20230411035604.GG47625@sol.localdomain> (raw)
In-Reply-To: <07509950e40e37344aac535a07d8176f680a7e18.1681155143.git.sweettea-kernel@dorminy.me>

On Mon, Apr 10, 2023 at 03:40:00PM -0400, Sweet Tea Dorminy wrote:
> +static const u8 FSCRYPT_POLICY_FLAGS_KEY_MASK =
> +	(FSCRYPT_POLICY_FLAG_DIRECT_KEY
> +	 | FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64
> +	 | FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32);

A comment describing the meaning of the above constant would be helpful.

> +static size_t fill_hkdf_info(const struct fscrypt_info *ci, u8 *hkdf_info)

Maybe call this fill_hkdf_info_for_mode_key() to avoid ambiguity with other uses
of HKDF?  Also, maybe add an explicit array size to hkdf_info?  E.g.
hkdf_info[MAX_MODE_KEY_HKDF_INFO_SIZE]

> +static u8 hkdf_context_for_policy(const union fscrypt_policy *policy)
> +{
> +	switch (fscrypt_policy_flags(policy) & FSCRYPT_POLICY_FLAGS_KEY_MASK) {
> +		case FSCRYPT_POLICY_FLAG_DIRECT_KEY:
> +			return HKDF_CONTEXT_DIRECT_KEY;
> +		case FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64:
> +			return HKDF_CONTEXT_IV_INO_LBLK_64_KEY;
> +		case FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32:
> +			return HKDF_CONTEXT_IV_INO_LBLK_32_KEY;
> +		default:
> +			return 0;
> +	}
> +}

There's an extra level of indentation above.

Also, more importantly, since fill_hkdf_info() checks the policy flags anyway,
maybe just handle the HKDF context bytes directly in there?  E.g.:

	if (ci->ci_policy.v2.flags & FSCRYPT_POLICY_FLAG_DIRECT_KEY) {
		hkdf_info[0] = HKDF_CONTEXT_DIRECT_KEY;
		return 1;
	}
	if (ci->ci_policy.v2.flags & FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32)
		hkdf_info[0] = HKDF_CONTEXT_IV_INO_LBLK_32_KEY;
	else
		hkdf_info[0] = HKDF_CONTEXT_IV_INO_LBLK_64_KEY;
	memcpy(&hkdf_info[1], &sb->s_uuid, sizeof(sb->s_uuid));
	return 1 + sizeof(sb->s_uuid);

- Eric

  reply	other threads:[~2023-04-11  3:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10 19:39 [PATCH v2 00/11] fscrypt: rearrangements preliminary to extent encryption Sweet Tea Dorminy
2023-04-10 19:39 ` [PATCH v2 01/11] fscrypt: move inline crypt decision to info setup Sweet Tea Dorminy
2023-04-10 19:39 ` [PATCH v2 02/11] fscrypt: split and rename setup_file_encryption_key() Sweet Tea Dorminy
2023-04-11  3:24   ` Eric Biggers
2023-04-10 19:39 ` [PATCH v2 03/11] fscrypt: split and rename setup_per_mode_enc_key() Sweet Tea Dorminy
2023-04-11  3:29   ` Eric Biggers
2023-04-10 19:39 ` [PATCH v2 04/11] fscrypt: move dirhash key setup away from IO key setup Sweet Tea Dorminy
2023-04-11  3:35   ` Eric Biggers
2023-04-10 19:39 ` [PATCH v2 05/11] fscrypt: reduce special-casing of IV_INO_LBLK_32 Sweet Tea Dorminy
2023-04-11  3:38   ` Eric Biggers
2023-04-10 19:39 ` [PATCH v2 06/11] fscrypt: make infos have a pointer to prepared keys Sweet Tea Dorminy
2023-04-11  3:44   ` Eric Biggers
2023-04-11 16:26     ` Sweet Tea Dorminy
2023-04-10 19:40 ` [PATCH v2 07/11] fscrypt: move all the shared mode key setup deeper Sweet Tea Dorminy
2023-04-11  3:56   ` Eric Biggers [this message]
2023-04-10 19:40 ` [PATCH v2 08/11] fscrypt: make ci->ci_direct_key a bool not a pointer Sweet Tea Dorminy
2023-04-11  3:57   ` Eric Biggers
2023-04-10 19:40 ` [PATCH v2 09/11] fscrypt: make prepared keys record their type Sweet Tea Dorminy
2023-04-10 19:40 ` [PATCH v2 10/11] fscrypt: explicitly track prepared parts of key Sweet Tea Dorminy
2023-04-11  4:05   ` Eric Biggers
2023-04-11 16:45     ` Sweet Tea Dorminy
2023-04-11 21:21       ` Eric Biggers
2023-04-10 19:40 ` [PATCH v2 11/11] fscrypt: split key alloc and preparation Sweet Tea Dorminy
2023-04-11  3:18 ` [PATCH v2 00/11] fscrypt: rearrangements preliminary to extent encryption 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=20230411035604.GG47625@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=kernel-team@meta.com \
    --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.