Re: [PATCH v6 09/17] soc: qcom: ice: add HWKM support to the ICE driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07/09/2024 00:07, Dmitry Baryshkov wrote:
On Fri, Sep 06, 2024 at 08:07:12PM GMT, Bartosz Golaszewski wrote:
From: Gaurav Kashyap <quic_gaurkash@xxxxxxxxxxx>

Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
management hardware called Hardware Key Manager (HWKM). Add HWKM support
to the ICE driver if it is available on the platform. HWKM primarily
provides hardware wrapped key support where the ICE (storage) keys are
not available in software and instead protected in hardware.

When HWKM software support is not fully available (from Trustzone), there
can be a scenario where the ICE hardware supports HWKM, but it cannot be
used for wrapped keys. In this case, raw keys have to be used without
using the HWKM. We query the TZ at run-time to find out whether wrapped
keys support is available.

Tested-by: Neil Armstrong <neil.armstrong@xxxxxxxxxx>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@xxxxxxxxxxx>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
---
  drivers/soc/qcom/ice.c | 152 +++++++++++++++++++++++++++++++++++++++++++++++--
  include/soc/qcom/ice.h |   1 +
  2 files changed, 149 insertions(+), 4 deletions(-)

  int qcom_ice_enable(struct qcom_ice *ice)
  {
+	int err;
+
  	qcom_ice_low_power_mode_enable(ice);
  	qcom_ice_optimization_enable(ice);
- return qcom_ice_wait_bist_status(ice);
+	if (ice->use_hwkm)
+		qcom_ice_enable_standard_mode(ice);
+
+	err = qcom_ice_wait_bist_status(ice);
+	if (err)
+		return err;
+
+	if (ice->use_hwkm)
+		qcom_ice_hwkm_init(ice);
+
+	return err;
  }
  EXPORT_SYMBOL_GPL(qcom_ice_enable);
@@ -150,6 +282,10 @@ int qcom_ice_resume(struct qcom_ice *ice)
  		return err;
  	}
+ if (ice->use_hwkm) {
+		qcom_ice_enable_standard_mode(ice);
+		qcom_ice_hwkm_init(ice);
+	}
  	return qcom_ice_wait_bist_status(ice);
  }
  EXPORT_SYMBOL_GPL(qcom_ice_resume);
@@ -157,6 +293,7 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
  int qcom_ice_suspend(struct qcom_ice *ice)
  {
  	clk_disable_unprepare(ice->core_clk);
+	ice->hwkm_init_complete = false;
return 0;
  }
@@ -206,6 +343,12 @@ int qcom_ice_evict_key(struct qcom_ice *ice, int slot)
  }
  EXPORT_SYMBOL_GPL(qcom_ice_evict_key);
+bool qcom_ice_hwkm_supported(struct qcom_ice *ice)
+{
+	return ice->use_hwkm;
+}
+EXPORT_SYMBOL_GPL(qcom_ice_hwkm_supported);
+
  static struct qcom_ice *qcom_ice_create(struct device *dev,
  					void __iomem *base)
  {
@@ -240,6 +383,7 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
  		engine->core_clk = devm_clk_get_enabled(dev, NULL);
  	if (IS_ERR(engine->core_clk))
  		return ERR_CAST(engine->core_clk);
+	engine->use_hwkm = qcom_scm_has_wrapped_key_support();

This still makes the decision on whether to use HW-wrapped keys on
behalf of a user. I suppose this is incorrect. The user must be able to
use raw keys even if HW-wrapped keys are available on the platform. One
of the examples for such use-cases is if a user prefers to be able to
recover stored information in case of a device failure (such recovery
will be impossible if SoC is damaged and HW-wrapped keys are used).

Isn't that already the case ? the BLK_CRYPTO_KEY_TYPE_HW_WRAPPED size is
here to select HW-wrapped key, otherwise the ol' raw key is passed.
Just look the next patch.

Or did I miss something ?

Neil


if (!qcom_ice_check_supported(engine))
  		return ERR_PTR(-EOPNOTSUPP);
diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
index 9dd835dba2a7..1f52e82e3e1c 100644
--- a/include/soc/qcom/ice.h
+++ b/include/soc/qcom/ice.h
@@ -34,5 +34,6 @@ int qcom_ice_program_key(struct qcom_ice *ice,
  			 const struct blk_crypto_key *bkey,
  			 u8 data_unit_size, int slot);
  int qcom_ice_evict_key(struct qcom_ice *ice, int slot);
+bool qcom_ice_hwkm_supported(struct qcom_ice *ice);
  struct qcom_ice *of_qcom_ice_get(struct device *dev);
  #endif /* __QCOM_ICE_H__ */

--
2.43.0







[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux