All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Gaurav Kashyap <quic_gaurkash@quicinc.com>
Cc: linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-block@vger.kernel.org,
	linux-fscrypt@vger.kernel.org, thara.gopinath@linaro.org,
	quic_neersoni@quicinc.com, dineshg@quicinc.com
Subject: Re: [PATCH 05/10] scsi: ufs: prepare to support wrapped keys
Date: Mon, 13 Dec 2021 17:26:57 -0800	[thread overview]
Message-ID: <Ybfy4UQCi8RkkE2Y@gmail.com> (raw)
In-Reply-To: <20211206225725.77512-6-quic_gaurkash@quicinc.com>

On Mon, Dec 06, 2021 at 02:57:20PM -0800, Gaurav Kashyap wrote:
> Adds support in ufshcd-core for wrapped keys.
> 1. Change program key vop to support wrapped key sizes by
>    using blk_crypto_key directly instead of using ufs_crypto_cfg
>    which is not suitable for wrapped keys.
> 2. Add derive_sw_secret vop and derive_sw_secret crypto_profile op.
> 
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/scsi/ufs/ufshcd-crypto.c | 52 +++++++++++++++++++++++++-------
>  drivers/scsi/ufs/ufshcd.h        |  9 +++++-
>  2 files changed, 49 insertions(+), 12 deletions(-)

There will be a build error if the patch series is applied just up to here,
since this patch changes the prototype of ufs_hba_variant_ops::program_key but
doesn't update ufs_qcom which implements it.

Every intermediate step needs to be buildable, and that's more important than
keeping changes to different drivers separate.

So I recommend having one patch that does the program_key change, in both
ufshcd-crypto.c and ufs-qcom-ice.c.

Adding derive_sw_secret should be a separate patch, and maybe should be combined
with the other new methods.

> diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
> index 0ed82741f981..9d68621a0eb4 100644
> --- a/drivers/scsi/ufs/ufshcd-crypto.c
> +++ b/drivers/scsi/ufs/ufshcd-crypto.c
> @@ -18,16 +18,23 @@ static const struct ufs_crypto_alg_entry {
>  };
>  
>  static int ufshcd_program_key(struct ufs_hba *hba,
> +			      const struct blk_crypto_key *key,
>  			      const union ufs_crypto_cfg_entry *cfg, int slot)
>  {
>  	int i;
>  	u32 slot_offset = hba->crypto_cfg_register + slot * sizeof(*cfg);
>  	int err = 0;
> +	bool evict = false;
>  
>  	ufshcd_hold(hba, false);
>  
>  	if (hba->vops && hba->vops->program_key) {
> -		err = hba->vops->program_key(hba, cfg, slot);
> +		if (!(cfg->config_enable & UFS_CRYPTO_CONFIGURATION_ENABLE))
> +			evict = true;
> +		err = hba->vops->program_key(hba, key, slot,
> +					     cfg->data_unit_size,
> +					     cfg->crypto_cap_idx,
> +					     evict);
>  		goto out;
>  	}

This is a little weird because here we've already gone through the trouble of
creating a 'union ufs_crypto_cfg_entry', only to throw it away in the
->program_key case and just use the original blk_crypto_key instead.

I think that this should be refactored a bit to make it so that a
'ufs_crypto_cfg_entry' is only be initialized if program_key is not implemented.

Also, note that 'struct blk_crypto_key' includes the data unit size.  So there's
no need to pass the data unit size as a separate argument to program_key.

> +static int ufshcd_crypto_derive_sw_secret(struct blk_crypto_profile *profile,
> +				const u8 *wrapped_key,
> +				unsigned int wrapped_key_size,
> +				u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE])
> +{
> +	struct ufs_hba *hba =
> +		container_of(profile, struct ufs_hba, crypto_profile);
> +
> +	if (hba->vops && hba->vops->derive_secret)
> +		return  hba->vops->derive_secret(hba, wrapped_key,
> +						 wrapped_key_size, sw_secret);

There's a weird double space here.

> @@ -190,7 +215,12 @@ int ufshcd_hba_init_crypto_capabilities(struct ufs_hba *hba)
>  	hba->crypto_profile.ll_ops = ufshcd_crypto_ops;
>  	/* UFS only supports 8 bytes for any DUN */
>  	hba->crypto_profile.max_dun_bytes_supported = 8;
> -	hba->crypto_profile.key_types_supported = BLK_CRYPTO_KEY_TYPE_STANDARD;
> +	if (hba->hw_wrapped_keys_supported)
> +		hba->crypto_profile.key_types_supported =
> +				BLK_CRYPTO_KEY_TYPE_HW_WRAPPED;
> +	else
> +		hba->crypto_profile.key_types_supported =
> +				BLK_CRYPTO_KEY_TYPE_STANDARD;

"hw_wrapped_keys_supported" is confusing because it doesn't just mean that
wrapped keys are supported, but also that standard keys are *not* supported.
"use_hw_wrapped_keys" would be clearer.

However, given that wrapped keys aren't specified by the UFS standard, I think
this better belongs as a bit in hba->quirks, like
UFSHCD_QUIRK_USES_WRAPPED_CRYPTO_KEYS.

> +	int	(*derive_secret)(struct ufs_hba *hba, const u8 *wrapped_key,
> +				 unsigned int wrapped_key_size,
> +				 u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]);

This probably should be called derive_sw_secret, not just derive_secret.

- Eric

  reply	other threads:[~2021-12-14  1:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-06 22:57 [PATCH 00/10] Add wrapped key support for Qualcomm ICE Gaurav Kashyap
2021-12-06 22:57 ` [PATCH 01/10] soc: qcom: new common library for ICE functionality Gaurav Kashyap
2021-12-07  0:24   ` Randy Dunlap
2021-12-14  0:20   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 02/10] scsi: ufs: qcom: move ICE functionality to common library Gaurav Kashyap
2021-12-14  0:40   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 03/10] qcom_scm: scm call for deriving a software secret Gaurav Kashyap
2021-12-14  0:53   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 04/10] soc: qcom: add HWKM library for storage encryption Gaurav Kashyap
2021-12-14  1:08   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 05/10] scsi: ufs: prepare to support wrapped keys Gaurav Kashyap
2021-12-14  1:26   ` Eric Biggers [this message]
2021-12-06 22:57 ` [PATCH 06/10] soc: qcom: add wrapped key support for ICE Gaurav Kashyap
2021-12-14  1:46   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 07/10] qcom_scm: scm call for create, prepare and import keys Gaurav Kashyap
2021-12-14  1:50   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 08/10] scsi: ufs: add support for generate, import and prepare keys Gaurav Kashyap
2021-12-14  1:53   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 09/10] soc: qcom: support for generate, import and prepare key Gaurav Kashyap
2021-12-14  2:04   ` Eric Biggers
2021-12-06 22:57 ` [PATCH 10/10] arm64: dts: qcom: sm8350: add ice and hwkm mappings Gaurav Kashyap
2022-01-06 19:47 ` [PATCH 00/10] Add wrapped key support for Qualcomm ICE Eric Biggers
2022-01-06 21:14   ` Gaurav Kashyap
2022-01-27  0:51     ` 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=Ybfy4UQCi8RkkE2Y@gmail.com \
    --to=ebiggers@kernel.org \
    --cc=dineshg@quicinc.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=quic_gaurkash@quicinc.com \
    --cc=quic_neersoni@quicinc.com \
    --cc=thara.gopinath@linaro.org \
    /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.