public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: Om Prakash Singh <quic_omprsing@quicinc.com>
To: Gaurav Kashyap <quic_gaurkash@quicinc.com>,
	<linux-arm-msm@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
	<andersson@kernel.org>, <ebiggers@google.com>,
	<neil.armstrong@linaro.org>, <srinivas.kandagatla@linaro.org>,
	<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
	<robh+dt@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-mmc@vger.kernel.org>,
	<kernel@quicinc.com>, <linux-crypto@vger.kernel.org>,
	<devicetree@vger.kernel.org>, <quic_nguyenb@quicinc.com>,
	<bartosz.golaszewski@linaro.org>, <konrad.dybcio@linaro.org>,
	<ulf.hansson@linaro.org>, <jejb@linux.ibm.com>,
	<martin.petersen@oracle.com>, <mani@kernel.org>,
	<davem@davemloft.net>, <herbert@gondor.apana.org.au>
Subject: Re: [PATCH v4 03/15] qcom_scm: scm call for create, prepare and import keys
Date: Mon, 5 Feb 2024 23:33:41 +0530	[thread overview]
Message-ID: <3e8cf072-b633-4c02-a296-2b09daccc805@quicinc.com> (raw)
In-Reply-To: <20240127232436.2632187-4-quic_gaurkash@quicinc.com>



On 1/28/2024 4:44 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 Qualcomm's Trustzone, 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>
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
>   drivers/firmware/qcom/qcom_scm.c       | 182 +++++++++++++++++++++++++
>   drivers/firmware/qcom/qcom_scm.h       |   3 +
>   include/linux/firmware/qcom/qcom_scm.h |   5 +
>   3 files changed, 190 insertions(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 4882f8a36453..20dbab765c8e 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -1285,6 +1285,188 @@ int qcom_scm_derive_sw_secret(const u8 *wkey, size_t wkey_size,
>   }
>   EXPORT_SYMBOL_GPL(qcom_scm_derive_sw_secret);
>   
> +/**
> + * qcom_scm_generate_ice_key() - Generate a wrapped key for encryption.
> + * @lt_key: the wrapped key returned after key generation
> + * @lt_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.
> + *
> + * Adds support for the create key IOCTL to interface
> + * with the secure environment to generate and return a wrapped key..
> + *
> + * Return: longterm key size on success; -errno on failure.
Why to return parameter input value? already has it. returning 0 on 
success should be the standard unless the returned key size would change.
> + */
> +int qcom_scm_generate_ice_key(u8 *lt_key, size_t lt_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] = lt_key_size,
> +		.owner = ARM_SMCCC_OWNER_SIP,
> +	};
> +
> +	void *lt_key_buf;
> +	int ret;
> +
> +	lt_key_buf = qcom_tzmem_alloc(__scm->mempool, lt_key_size, GFP_KERNEL);
> +	if (!lt_key_buf)
> +		return -ENOMEM;
> +
> +	desc.args[0] = qcom_tzmem_to_phys(lt_key_buf);
> +
> +	ret = qcom_scm_call(__scm->dev, &desc, NULL);
> +	if (!ret)
> +		memcpy(lt_key, lt_key_buf, lt_key_size);
> +
> +	memzero_explicit(lt_key_buf, lt_key_size);
> +	qcom_tzmem_free(lt_key_buf);
> +
> +	if (!ret)
> +		return lt_key_size;
return 0 on success. lt_key_size is input value. Caller already has it.
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_scm_generate_ice_key);
> +
> +/**
> + * qcom_scm_prepare_ice_key() - Get per boot ephemeral wrapped key
> + * @lt_key: the longterm wrapped key
> + * @lt_key_size: size of the wrapped key
> + * @eph_key: ephemeral wrapped key to be returned
> + * @eph_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.
> + *
> + * Adds support for the create key IOCTL to interface
> + * with the secure environment to rewrap the wrapped key with an
> + * ephemeral wrapping key.
> + *
> + * Return: ephemeral key size on success; -errno on failure.
> + */
> +int qcom_scm_prepare_ice_key(const u8 *lt_key, size_t lt_key_size,
> +			     u8 *eph_key, size_t eph_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] = lt_key_size,
> +		.args[3] = eph_key_size,
> +		.owner = ARM_SMCCC_OWNER_SIP,
> +	};
> +
> +	void *eph_key_buf;
> +	void *lt_key_buf;
> +	int ret;
> +
> +	lt_key_buf = qcom_tzmem_alloc(__scm->mempool, lt_key_size, GFP_KERNEL);
> +	if (!lt_key_buf)
> +		return -ENOMEM;
> +	eph_key_buf = qcom_tzmem_alloc(__scm->mempool, eph_key_size, GFP_KERNEL);
> +	if (!eph_key_buf) {
> +		ret = -ENOMEM;
> +		goto err_free_longterm;
> +	}
> +
> +	memcpy(lt_key_buf, lt_key, lt_key_size);
> +	desc.args[0] = qcom_tzmem_to_phys(lt_key_buf);
> +	desc.args[2] = qcom_tzmem_to_phys(eph_key_buf);
> +
> +	ret = qcom_scm_call(__scm->dev, &desc, NULL);
> +	if (!ret)
> +		memcpy(eph_key, eph_key_buf, eph_key_size);
> +
> +	memzero_explicit(eph_key_buf, eph_key_size);
> +	qcom_tzmem_free(eph_key_buf);
> +
> +err_free_longterm:
> +	memzero_explicit(lt_key_buf, lt_key_size);
> +	qcom_tzmem_free(lt_key_buf);
> +
> +	if (!ret)
> +		return eph_key_size;
return 0 on success. eph_key_size is input value. Caller already has it.
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_scm_prepare_ice_key);
> +
> +/**
> + * qcom_scm_import_ice_key() - Import a wrapped key for encryption
> + * @imp_key: the raw key that is imported
> + * @imp_key_size: size of the key to be imported
> + * @lt_key: the wrapped key to be returned
> + * @lt_key_size: size of the wrapped key
> + *
> + * Conceptually, this is very similar to generate, the difference being,
> + * here we want to import a raw key and return a longterm wrapped key
> + * from it. The same create key IOCTL is used to achieve this.
> + *
> + * Adds support for the create key IOCTL to interface with
> + * the secure environment to import a raw key and generate a longterm
> + * wrapped key.
> + *
> + * Return: longterm key size on success; -errno on failure.
> + */
> +int qcom_scm_import_ice_key(const u8 *imp_key, size_t imp_key_size,
> +			    u8 *lt_key, size_t lt_key_size)
> +{
> +	struct qcom_scm_desc desc = {
> +		.svc = QCOM_SCM_SVC_ES,
> +		.cmd =  QCOM_SCM_ES_IMPORT_ICE_KEY,
> +		.arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_RO,
> +					 QCOM_SCM_VAL, QCOM_SCM_RW,
> +					 QCOM_SCM_VAL),
> +		.args[1] = imp_key_size,
> +		.args[3] = lt_key_size,
> +		.owner = ARM_SMCCC_OWNER_SIP,
> +	};
> +
> +	void *imp_key_buf;
> +	void *lt_key_buf;
> +	int ret;
> +
> +	imp_key_buf = qcom_tzmem_alloc(__scm->mempool, imp_key_size, GFP_KERNEL);
> +	if (!imp_key_buf)
> +		return -ENOMEM;
> +	lt_key_buf = qcom_tzmem_alloc(__scm->mempool, lt_key_size, GFP_KERNEL);
> +	if (!lt_key_buf) {
> +		ret = -ENOMEM;
> +		goto err_free_longterm;
> +	}
> +
> +	memcpy(imp_key_buf, imp_key, imp_key_size);
> +	desc.args[0] = qcom_tzmem_to_phys(imp_key_buf);
> +	desc.args[2] = qcom_tzmem_to_phys(lt_key_buf);
> +
> +	ret = qcom_scm_call(__scm->dev, &desc, NULL);
> +	if (!ret)
> +		memcpy(lt_key, lt_key_buf, lt_key_size);
> +
> +	memzero_explicit(lt_key_buf, lt_key_size);
> +	qcom_tzmem_free(lt_key_buf);
> +
> +err_free_longterm:
> +	memzero_explicit(imp_key_buf, imp_key_size);
> +	qcom_tzmem_free(imp_key_buf);
> +
> +	if (!ret)
> +		return lt_key_size;
return 0 on success. lt_key_size is input value. Caller already has it.
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_scm_import_ice_key);
> +
>   /**
>    * qcom_scm_hdcp_available() - Check if secure environment supports HDCP.
>    *
> diff --git a/drivers/firmware/qcom/qcom_scm.h b/drivers/firmware/qcom/qcom_scm.h
> index 56ff0806f5d2..c30d6383b6de 100644
> --- a/drivers/firmware/qcom/qcom_scm.h
> +++ b/drivers/firmware/qcom/qcom_scm.h
> @@ -128,6 +128,9 @@ struct qcom_tzmem_pool *qcom_scm_get_tzmem_pool(void);
>   #define QCOM_SCM_ES_INVALIDATE_ICE_KEY	0x03
>   #define QCOM_SCM_ES_CONFIG_SET_ICE_KEY	0x04
>   #define QCOM_SCM_ES_DERIVE_SW_SECRET	0x07
> +#define QCOM_SCM_ES_GENERATE_ICE_KEY	0x08
> +#define QCOM_SCM_ES_PREPARE_ICE_KEY	0x09
> +#define QCOM_SCM_ES_IMPORT_ICE_KEY	0xA
>   
>   #define QCOM_SCM_SVC_HDCP		0x11
>   #define QCOM_SCM_HDCP_INVOKE		0x01
> diff --git a/include/linux/firmware/qcom/qcom_scm.h b/include/linux/firmware/qcom/qcom_scm.h
> index 89358478ac67..a0983a40bc09 100644
> --- a/include/linux/firmware/qcom/qcom_scm.h
> +++ b/include/linux/firmware/qcom/qcom_scm.h
> @@ -105,6 +105,11 @@ int qcom_scm_ice_set_key(u32 index, const u8 *key, u32 key_size,
>   			 enum qcom_scm_ice_cipher cipher, u32 data_unit_size);
>   int qcom_scm_derive_sw_secret(const u8 *wkey, size_t wkey_size,
>   			      u8 *sw_secret, size_t sw_secret_size);
> +int qcom_scm_generate_ice_key(u8 *lt_key, size_t lt_key_size);
> +int qcom_scm_prepare_ice_key(const u8 *lt_key, size_t lt_key_size,
> +			     u8 *eph_key, size_t eph_size);
> +int qcom_scm_import_ice_key(const u8 *imp_key, size_t imp_size,
> +			    u8 *lt_key, size_t lt_key_size);
>   
>   bool qcom_scm_hdcp_available(void);
>   int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp);

  reply	other threads:[~2024-02-05 18:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-27 23:13 [PATCH v4 00/15] Hardware wrapped key support for qcom ice and ufs Gaurav Kashyap
2024-01-27 23:13 ` [PATCH v4 01/15] ice, ufs, mmc: use blk_crypto_key for program_key Gaurav Kashyap
2024-02-06 11:46   ` Bartosz Golaszewski
2024-02-13 12:49   ` Ulf Hansson
2024-01-27 23:14 ` [PATCH v4 02/15] qcom_scm: scm call for deriving a software secret Gaurav Kashyap
2024-01-30  4:43   ` Bjorn Andersson
2024-02-01 16:11   ` Konrad Dybcio
2024-02-06 11:56     ` Bartosz Golaszewski
2024-01-27 23:14 ` [PATCH v4 03/15] qcom_scm: scm call for create, prepare and import keys Gaurav Kashyap
2024-02-05 18:03   ` Om Prakash Singh [this message]
2024-02-06 11:59   ` Bartosz Golaszewski
2024-01-27 23:14 ` [PATCH v4 04/15] soc: qcom: ice: add hwkm support in ice Gaurav Kashyap
2024-02-04 18:32   ` [EXTERNAL] " Kamlesh Gurudasani
2024-02-05 18:22   ` Om Prakash Singh
2024-01-27 23:14 ` [PATCH v4 05/15] soc: qcom: ice: support for hardware wrapped keys Gaurav Kashyap
2024-02-04 19:30   ` [EXTERNAL] " Kamlesh Gurudasani
2024-02-05 18:38   ` Om Prakash Singh
2024-01-27 23:14 ` [PATCH v4 06/15] soc: qcom: ice: support for generate, import and prepare key Gaurav Kashyap
2024-02-05 18:45   ` Om Prakash Singh
2024-01-27 23:14 ` [PATCH v4 07/15] ufs: core: support wrapped keys in ufs core Gaurav Kashyap
2024-01-27 23:14 ` [PATCH v4 08/15] ufs: core: add support to derive software secret Gaurav Kashyap
2024-02-05 18:52   ` Om Prakash Singh
2024-01-27 23:14 ` [PATCH v4 09/15] ufs: core: add support for generate, import and prepare keys Gaurav Kashyap
2024-02-05 18:53   ` Om Prakash Singh
2024-01-27 23:14 ` [PATCH v4 10/15] ufs: host: wrapped keys support in ufs qcom Gaurav Kashyap
2024-02-05 18:59   ` Om Prakash Singh
2024-01-27 23:14 ` [PATCH v4 11/15] ufs: host: implement derive sw secret vop " Gaurav Kashyap
2024-01-27 23:14 ` [PATCH v4 12/15] ufs: host: support for generate, import and prepare key Gaurav Kashyap
2024-01-27 23:14 ` [PATCH v4 13/15] dt-bindings: crypto: ice: document the hwkm property Gaurav Kashyap
2024-01-29  8:18   ` Krzysztof Kozlowski
2024-02-01 19:13     ` Konrad Dybcio
2024-06-18  0:26       ` Gaurav Kashyap (QUIC)
2024-01-27 23:14 ` [PATCH v4 14/15] arm64: dts: qcom: sm8650: add hwkm support to ufs ice Gaurav Kashyap
2024-01-29  8:15   ` Krzysztof Kozlowski
2024-01-27 23:14 ` [PATCH v4 15/15] arm64: dts: qcom: sm8550: " Gaurav Kashyap
2024-01-28  1:01   ` Dmitry Baryshkov
2024-02-01  9:55     ` Om Prakash Singh
2024-02-01 13:59       ` neil.armstrong

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=3e8cf072-b633-4c02-a296-2b09daccc805@quicinc.com \
    --to=quic_omprsing@quicinc.com \
    --cc=andersson@kernel.org \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=ebiggers@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jejb@linux.ibm.com \
    --cc=kernel@quicinc.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=neil.armstrong@linaro.org \
    --cc=quic_gaurkash@quicinc.com \
    --cc=quic_nguyenb@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=ulf.hansson@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox