Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Trilok Soni <quic_tsoni@quicinc.com>
To: Gaurav Kashyap <quic_gaurkash@quicinc.com>,
	<linux-scsi@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
	<ebiggers@google.com>
Cc: <linux-mmc@vger.kernel.org>, <linux-block@vger.kernel.org>,
	<linux-fscrypt@vger.kernel.org>, <omprsing@qti.qualcomm.com>,
	<quic_psodagud@quicinc.com>, <avmenon@quicinc.com>,
	<abel.vesa@linaro.org>, <quic_spuppala@quicinc.com>
Subject: Re: [PATCH v2 07/10] qcom_scm: scm call for create, prepare and import keys
Date: Wed, 19 Jul 2023 10:48:36 -0700	[thread overview]
Message-ID: <62207b82-92c1-e666-67e4-420a112c281f@quicinc.com> (raw)
In-Reply-To: <20230719170423.220033-8-quic_gaurkash@quicinc.com>

On 7/19/2023 10:04 AM, Gaurav Kashyap wrote:
> Storage encryption has two IOCTLs for creating, importing
> and preparing keys for encryption. For wrapped keys, these
> IOCTLs need to interface with the secure environment, which
> require these SCM calls.
> 
> generate_key: This is used to generate and return a longterm
>                wrapped key. Trustzone achieves this by generating
> 	      a key and then wrapping it using hwkm, returning
> 	      a wrapped keyblob.
> import_key:   The functionality is similar to generate, but here,
>                a raw key is imported into hwkm and a longterm wrapped
> 	      keyblob is returned.
> prepare_key:  The longterm wrapped key from import or generate
>                is made further secure by rewrapping it with a per-boot
> 	      ephemeral wrapped key before installing it to the linux
> 	      kernel for programming to ICE.
> 
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>   drivers/firmware/qcom_scm.c            | 222 +++++++++++++++++++++++++
>   drivers/firmware/qcom_scm.h            |   3 +
>   include/linux/firmware/qcom/qcom_scm.h |  10 ++
>   3 files changed, 235 insertions(+)
> 
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 51062d5c7f7b..44dd1857747b 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -1210,6 +1210,228 @@ int qcom_scm_derive_sw_secret(const u8 *wrapped_key, u32 wrapped_key_size,
>   }
>   EXPORT_SYMBOL(qcom_scm_derive_sw_secret);
>   
> +/**
> + * qcom_scm_generate_ice_key() - Generate a wrapped key for encryption.
> + * @longterm_wrapped_key: the wrapped key returned after key generation
> + * @longterm_wrapped_key_size: size of the wrapped key to be returned.
> + *
> + * Qualcomm wrapped keys need to be generated in a trusted environment.
> + * A generate key  IOCTL call is used to achieve this. These are longterm
> + * in nature as they need to be generated and wrapped only once per
> + * requirement.
> + *
> + * This SCM calls adds support for the generate key IOCTL to interface
> + * with the secure environment to generate and return a wrapped key..
> + *
> + * Return: 0 on success; -errno on failure.
> + */
> +int qcom_scm_generate_ice_key(u8 *longterm_wrapped_key,
> +			    u32 longterm_wrapped_key_size)
> +{
> +	struct qcom_scm_desc desc = {
> +		.svc = QCOM_SCM_SVC_ES,
> +		.cmd =  QCOM_SCM_ES_GENERATE_ICE_KEY,
> +		.arginfo = QCOM_SCM_ARGS(2, QCOM_SCM_RW,
> +					 QCOM_SCM_VAL),
> +		.args[1] = longterm_wrapped_key_size,
> +		.owner = ARM_SMCCC_OWNER_SIP,
> +	};
> +
> +	void *longterm_wrapped_keybuf;
> +	dma_addr_t longterm_wrapped_key_phys;
> +	int ret;
> +
> +	/*
> +	 * Like qcom_scm_ice_set_key(), we use dma_alloc_coherent() to properly
> +	 * get a physical address, while guaranteeing that we can zeroize the
> +	 * key material later using memzero_explicit().
> +	 *
> +	 */
> +	longterm_wrapped_keybuf = dma_alloc_coherent(__scm->dev,
> +				  longterm_wrapped_key_size,
> +				  &longterm_wrapped_key_phys, GFP_KERNEL);
> +	if (!longterm_wrapped_keybuf)
> +		return -ENOMEM;
> +
> +	desc.args[0] = longterm_wrapped_key_phys;
> +
> +	ret = qcom_scm_call(__scm->dev, &desc, NULL);
> +	memcpy(longterm_wrapped_key, longterm_wrapped_keybuf,
> +	       longterm_wrapped_key_size);
> +
> +	memzero_explicit(longterm_wrapped_keybuf, longterm_wrapped_key_size);
> +	dma_free_coherent(__scm->dev, longterm_wrapped_key_size,
> +			  longterm_wrapped_keybuf, longterm_wrapped_key_phys);
> +
> +	if (!ret)
> +		return longterm_wrapped_key_size;
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL(qcom_scm_generate_ice_key);
> +
> +/**
> + * qcom_scm_prepare_ice_key() - Get per boot ephemeral wrapped key
> + * @longterm_wrapped_key: the wrapped key
> + * @longterm_wrapped_key_size: size of the wrapped key
> + * @ephemeral_wrapped_key: ephemeral wrapped key to be returned
> + * @ephemeral_wrapped_key_size: size of the ephemeral wrapped key
> + *
> + * Qualcomm wrapped keys (longterm keys) are rewrapped with a per-boot
> + * ephemeral key for added protection. These are ephemeral in nature as
> + * they are valid only for that boot. A create key IOCTL is used to
> + * achieve this. These are the keys that are installed into the kernel
> + * to be then unwrapped and programmed into ICE.
> + *
> + * This SCM call adds support for the create key IOCTL to interface
> + * with the secure environment to rewrap the wrapped key with an
> + * ephemeral wrapping key.
> + *
> + * Return: 0 on success; -errno on failure.
> + */
> +int qcom_scm_prepare_ice_key(const u8 *longterm_wrapped_key,
> +			     u32 longterm_wrapped_key_size,
> +			     u8 *ephemeral_wrapped_key,
> +			     u32 ephemeral_wrapped_key_size)
> +{
> +	struct qcom_scm_desc desc = {
> +		.svc = QCOM_SCM_SVC_ES,
> +		.cmd =  QCOM_SCM_ES_PREPARE_ICE_KEY,
> +		.arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_RO,
> +					 QCOM_SCM_VAL, QCOM_SCM_RW,
> +					 QCOM_SCM_VAL),
> +		.args[1] = longterm_wrapped_key_size,
> +		.args[3] = ephemeral_wrapped_key_size,
> +		.owner = ARM_SMCCC_OWNER_SIP,
> +	};
> +
> +	void *longterm_wrapped_keybuf, *ephemeral_wrapped_keybuf;
> +	dma_addr_t longterm_wrapped_key_phys, ephemeral_wrapped_key_phys;
> +	int ret;
> +
> +	/*
> +	 * Like qcom_scm_ice_set_key(), we use dma_alloc_coherent() to properly
> +	 * get a physical address, while guaranteeing that we can zeroize the
> +	 * key material later using memzero_explicit().
> +	 *
> +	 */
> +	longterm_wrapped_keybuf = dma_alloc_coherent(__scm->dev,
> +				  longterm_wrapped_key_size,
> +				  &longterm_wrapped_key_phys, GFP_KERNEL);
> +	if (!longterm_wrapped_keybuf)
> +		return -ENOMEM;
> +	ephemeral_wrapped_keybuf = dma_alloc_coherent(__scm->dev,
> +				   ephemeral_wrapped_key_size,
> +				   &ephemeral_wrapped_key_phys, GFP_KERNEL);
> +	if (!ephemeral_wrapped_keybuf) {
> +		ret = -ENOMEM;
> +		goto bail_keybuf;
> +	}
> +
> +	memcpy(longterm_wrapped_keybuf, longterm_wrapped_key,
> +	       longterm_wrapped_key_size);
> +	desc.args[0] = longterm_wrapped_key_phys;
> +	desc.args[2] = ephemeral_wrapped_key_phys;
> +
> +	ret = qcom_scm_call(__scm->dev, &desc, NULL);
> +	if (!ret)
> +		memcpy(ephemeral_wrapped_key, ephemeral_wrapped_keybuf,
> +		       ephemeral_wrapped_key_size);
> +
> +	memzero_explicit(ephemeral_wrapped_keybuf, ephemeral_wrapped_key_size);
> +	dma_free_coherent(__scm->dev, ephemeral_wrapped_key_size,
> +			  ephemeral_wrapped_keybuf,
> +			  ephemeral_wrapped_key_phys);
> +
> +bail_keybuf:
> +	memzero_explicit(longterm_wrapped_keybuf, longterm_wrapped_key_size);
> +	dma_free_coherent(__scm->dev, longterm_wrapped_key_size,
> +			  longterm_wrapped_keybuf, longterm_wrapped_key_phys);
> +
> +	if (!ret)
> +		return ephemeral_wrapped_key_size;
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL(qcom_scm_prepare_ice_key);

EXPORT_SYMBOL_GPL everywhere please. I understand that other places in 
this file uses EXPORT_SYMBOL but new additions can be _GPL. I will see 
if someone from my team can covert other symbols to _GPL as well in this 
file.

---Trilok Soni

  reply	other threads:[~2023-07-19 17:48 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19 17:04 [PATCH v2 00/10] Hardware wrapped key support for qcom ice and ufs Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 01/10] ice, ufs, mmc: use blk_crypto_key for program_key Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 02/10] qcom_scm: scm call for deriving a software secret Gaurav Kashyap
2023-07-22  3:50   ` Bjorn Andersson
2023-07-22  4:18     ` Eric Biggers
2023-07-22 17:31       ` Bjorn Andersson
2023-07-19 17:04 ` [PATCH v2 03/10] soc: qcom: ice: add hwkm support in ice Gaurav Kashyap
2023-08-31  8:39   ` Neil Armstrong
2023-07-19 17:04 ` [PATCH v2 04/10] soc: qcom: ice: support for hardware wrapped keys Gaurav Kashyap
2023-08-31  9:10   ` Neil Armstrong
2023-07-19 17:04 ` [PATCH v2 05/10] ufs: core: support wrapped keys in ufs core Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 06/10] ufs: host: wrapped keys support in ufs qcom Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 07/10] qcom_scm: scm call for create, prepare and import keys Gaurav Kashyap
2023-07-19 17:48   ` Trilok Soni [this message]
2023-07-22  3:40   ` Bjorn Andersson
2023-07-22  4:11     ` Eric Biggers
2023-07-22 17:32       ` Bjorn Andersson
2023-07-19 17:04 ` [PATCH v2 08/10] ufs: core: add support for generate, import and prepare keys Gaurav Kashyap
2023-07-19 17:04 ` [PATCH v2 09/10] soc: qcom: support for generate, import and prepare key Gaurav Kashyap
2023-07-22  3:56   ` Bjorn Andersson
2023-07-19 17:04 ` [PATCH v2 10/10] ufs: host: " Gaurav Kashyap
2023-07-20  2:55 ` [PATCH v2 00/10] Hardware wrapped key support for qcom ice and ufs Eric Biggers
2023-08-01 17:31   ` Gaurav Kashyap (QUIC)
2023-08-10  5:36     ` Eric Biggers
2023-08-11  0:27       ` Gaurav Kashyap (QUIC)
2023-08-11  2:19         ` Bjorn Andersson
2023-08-25 10:19 ` Srinivas Kandagatla
2023-08-25 21:07   ` Eric Biggers
2023-08-29 17:11     ` Srinivas Kandagatla
2023-08-29 18:12       ` Eric Biggers
2023-08-30 10:00         ` Srinivas Kandagatla
2023-08-30 16:12           ` Eric Biggers
2023-08-30 16:44             ` Srinivas Kandagatla
2023-09-12 10:06     ` Srinivas Kandagatla
2023-09-19 23:18       ` Gaurav Kashyap
2023-08-29 21:06 ` Konrad Dybcio

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=62207b82-92c1-e666-67e4-420a112c281f@quicinc.com \
    --to=quic_tsoni@quicinc.com \
    --cc=abel.vesa@linaro.org \
    --cc=avmenon@quicinc.com \
    --cc=ebiggers@google.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=omprsing@qti.qualcomm.com \
    --cc=quic_gaurkash@quicinc.com \
    --cc=quic_psodagud@quicinc.com \
    --cc=quic_spuppala@quicinc.com \
    /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