On 6.09.2024 8:07 PM, Bartosz Golaszewski wrote:
> From: Gaurav Kashyap <quic_gaurkash@xxxxxxxxxxx>
>
> Add a new UFS core callback for deriving software secrets from hardware
> wrapped keys and implement it in QCom UFS.
>
> Tested-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@xxxxxxxxxxx>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> ---
> drivers/ufs/host/ufs-qcom.c | 15 +++++++++++++++
> include/ufs/ufshcd.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 366fd62a951f..77fb5e66e4be 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -182,9 +182,23 @@ static int ufs_qcom_ice_program_key(struct ufs_hba *hba,
> return qcom_ice_evict_key(host->ice, slot);
> }
>
> +/*
> + * Derive a software secret from a hardware wrapped key. The key is unwrapped in
> + * hardware from trustzone and a software key/secret is then derived from it.
> + */
> +static int ufs_qcom_ice_derive_sw_secret(struct ufs_hba *hba, const u8 wkey[],
> + unsigned int wkey_size,
> + u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE])
> +{
> + struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> +
> + return qcom_ice_derive_sw_secret(host->ice, wkey, wkey_size, sw_secret);
> +}
There's platforms with multiple UFS hosts (e.g. 8280 has one with the
intention to be used for an onboard flash and one for a UFS card (they're
like microSD except they're UFS and not MMC).. We need to handle that
somehow too.
My uneducated guess would be that the encryption infra is there for the
primary host only and that it would be the one assumed by SCM calls.
I thiiiink it should be enough not to add a `qcom,ice` property in the
DT for the secondary slot, but please somebody else take another look
here
Konrad
