[PATCH v5 00/15] Hardware wrapped key support for qcom ice and ufs

[PATCH v5 00/15] Hardware wrapped key support for qcom ice and ufs

[Gaurav Kashyap]

The fifth iteration of patches that add support to Qualcomm ICE (Inline Crypto Engine) for hardware wrapped keys using Qualcomm Hardware Key Manager (HWKM)

They patches do the following:
- Address comments from previous versions (https://lore.kernel.org/all/20240127232436.2632187-1-quic_gaurkash@quicinc.com/)
- Tested on top of Eric's latest fscrypt and block set: https://lore.kernel.org/all/20231104211259.17448-1-ebiggers@kernel.org/
- Rebased and tested on top of Linaro's SHMBridge patches: (https://lore.kernel.org/all/20240527-shm-bridge-v10-0-ce7afaa58d3a@linaro.org/)

Explanation and use of hardware-wrapped-keys can be found here:
Documentation/block/inline-encryption.rst

Testing: 
Test platform: SM8650 MTP

The changes were tested by mounting initramfs and running the fscryptctl
tool (Ref: https://github.com/ebiggers/fscryptctl/tree/wip-wrapped-keys) to
generate and prepare keys, as well as to set policies on folders, which
consequently invokes disk encryption flows through UFS.

Tested both standard and wrapped keys (Removing qcom,ice-use-hwkm from dtsi will support using standard keys)

Steps to test:

The following configs were enabled:
CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_QCOM_INLINE_CRYPTO_ENGINE=m
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
CONFIG_SCSI_UFS_CRYPTO=y

Flash boot image to shell and run the following commands

Creating and preparing keys
- mkfs.ext4 -F -O encrypt,stable_inodes /dev/disk/by-partlabel/userdata
- mount /dev/disk/by-partlabel/userdata -o inlinecrypt /mnt
- ./fscryptctl generate_hw_wrapped_key /dev/disk/by-partlabel/userdata > /mnt/key.longterm  OR dd if=/dev/zero bs=32 count=1 | tr '\0' 'X' \ | fscryptctl import_hw_wrapped_key $BLOCKDEV > /mnt/key.longterm
- ./fscryptctl prepare_hw_wrapped_key /dev/disk/by-partlabel/userdata < /mnt/key.longterm > /tmp/key.ephemeral
- ./fscryptctl add_key --hw-wrapped-key < /tmp/key.ephemeral /mnt

Create a folder and associate created keys with the folder
- rm -rf /mnt/dir
- mkdir /mnt/dir
- ./fscryptctl set_policy --hw-wrapped-key --iv-ino-lblk-64 "$keyid" /mnt/dir
- dmesg > /mnt/dir/test.txt
- sync

- Reboot
- mount /dev/disk/by-partlabel/userdata -o inlinecrypt /mnt
- ls /mnt/dir (You should see an encrypted file)
- ./fscryptctl prepare_hw_wrapped_key /dev/disk/by-partlabel/userdata < /mnt/key.longterm > /tmp/key.ephemeral
- 

- cat /mnt/dir/test.txt

NOTE: Evicting a key with HWKM is not supported in the current SCM call for HWKM v2 chipsets, TZ already supports a different call for this.
Changes will be added separately for these after further internal discussions. But this should not stop merging the existing patches.

Merge Strategy:

This is an open-ended question to the community and the respective component maintainers.
The changes have the following components.

- SHMBridge patches (Bartosz Golaszewski)
- Fscrypt and block patches (From Eric Biggers)
- Qualcomm SCM (This patchset)
- Qualcomm ICE (This patchset)
- UFS Core ((This patchset))
- Qualcomm UFS Host (This patchset)

It would be ideal if one maintainer can take in all the changes together since working with many immutable branches shared with each other might get tricky.

Gaurav Kashyap (15):
  ice, ufs, mmc: use blk_crypto_key for program_key
  qcom_scm: scm call for deriving a software secret
  qcom_scm: scm call for create, prepare and import keys
  soc: qcom: ice: add hwkm support in ice
  soc: qcom: ice: support for hardware wrapped keys
  soc: qcom: ice: support for generate, import and prepare key
  ufs: core: support wrapped keys in ufs core
  ufs: core: add support to derive software secret
  ufs: core: add support for generate, import and prepare keys
  ufs: host: wrapped keys support in ufs qcom
  ufs: host: implement derive sw secret vop in ufs qcom
  ufs: host: support for generate, import and prepare key
  dt-bindings: crypto: ice: document the hwkm property
  arm64: dts: qcom: sm8650: add hwkm support to ufs ice
  arm64: dts: qcom: sm8550: add hwkm support to ufs ice

 .../crypto/qcom,inline-crypto-engine.yaml     |  10 +
 arch/arm64/boot/dts/qcom/sm8550.dtsi          |   5 +-
 arch/arm64/boot/dts/qcom/sm8650.dtsi          |   4 +-
 drivers/firmware/qcom/qcom_scm.c              | 240 ++++++++++++
 drivers/firmware/qcom/qcom_scm.h              |   4 +
 drivers/mmc/host/cqhci-crypto.c               |   7 +-
 drivers/mmc/host/cqhci.h                      |   2 +
 drivers/mmc/host/sdhci-msm.c                  |   6 +-
 drivers/soc/qcom/ice.c                        | 351 +++++++++++++++++-
 drivers/ufs/core/ufshcd-crypto.c              |  87 ++++-
 drivers/ufs/host/ufs-qcom.c                   |  61 ++-
 include/linux/firmware/qcom/qcom_scm.h        |   7 +
 include/soc/qcom/ice.h                        |  18 +-
 include/ufs/ufshcd.h                          |  22 ++
 14 files changed, 785 insertions(+), 39 deletions(-)

-- 
2.43.0

[PATCH v5 01/15] ice, ufs, mmc: use blk_crypto_key for program_key

[Gaurav Kashyap]

The program key ops in the storage controller does not
pass on the blk crypto key structure to ice, this is okay
when wrapped keys are not supported and keys are standard
AES XTS sizes. However, wrapped keyblobs can be of any size
and in preparation for that, modify the ICE and storage
controller APIs to accept blk_crypto_key.

Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/mmc/host/cqhci-crypto.c  | 7 ++++---
 drivers/mmc/host/cqhci.h         | 2 ++
 drivers/mmc/host/sdhci-msm.c     | 6 ++++--
 drivers/soc/qcom/ice.c           | 6 +++---
 drivers/ufs/core/ufshcd-crypto.c | 7 ++++---
 drivers/ufs/host/ufs-qcom.c      | 6 ++++--
 include/soc/qcom/ice.h           | 5 +++--
 include/ufs/ufshcd.h             | 1 +
 8 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/host/cqhci-crypto.c b/drivers/mmc/host/cqhci-crypto.c
index 6652982410ec..91da6de1d650 100644
--- a/drivers/mmc/host/cqhci-crypto.c
+++ b/drivers/mmc/host/cqhci-crypto.c
@@ -32,6 +32,7 @@ cqhci_host_from_crypto_profile(struct blk_crypto_profile *profile)
 }
 
 static int cqhci_crypto_program_key(struct cqhci_host *cq_host,
+				    const struct blk_crypto_key *bkey,
 				    const union cqhci_crypto_cfg_entry *cfg,
 				    int slot)
 {
@@ -39,7 +40,7 @@ static int cqhci_crypto_program_key(struct cqhci_host *cq_host,
 	int i;
 
 	if (cq_host->ops->program_key)
-		return cq_host->ops->program_key(cq_host, cfg, slot);
+		return cq_host->ops->program_key(cq_host, bkey, cfg, slot);
 
 	/* Clear CFGE */
 	cqhci_writel(cq_host, 0, slot_offset + 16 * sizeof(cfg->reg_val[0]));
@@ -99,7 +100,7 @@ static int cqhci_crypto_keyslot_program(struct blk_crypto_profile *profile,
 		memcpy(cfg.crypto_key, key->raw, key->size);
 	}
 
-	err = cqhci_crypto_program_key(cq_host, &cfg, slot);
+	err = cqhci_crypto_program_key(cq_host, key, &cfg, slot);
 
 	memzero_explicit(&cfg, sizeof(cfg));
 	return err;
@@ -113,7 +114,7 @@ static int cqhci_crypto_clear_keyslot(struct cqhci_host *cq_host, int slot)
 	 */
 	union cqhci_crypto_cfg_entry cfg = {};
 
-	return cqhci_crypto_program_key(cq_host, &cfg, slot);
+	return cqhci_crypto_program_key(cq_host, NULL, &cfg, slot);
 }
 
 static int cqhci_crypto_keyslot_evict(struct blk_crypto_profile *profile,
diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h
index fab9d74445ba..06099fd32f23 100644
--- a/drivers/mmc/host/cqhci.h
+++ b/drivers/mmc/host/cqhci.h
@@ -12,6 +12,7 @@
 #include <linux/completion.h>
 #include <linux/wait.h>
 #include <linux/irqreturn.h>
+#include <linux/blk-crypto.h>
 #include <asm/io.h>
 
 /* registers */
@@ -291,6 +292,7 @@ struct cqhci_host_ops {
 	void (*post_disable)(struct mmc_host *mmc);
 #ifdef CONFIG_MMC_CRYPTO
 	int (*program_key)(struct cqhci_host *cq_host,
+			   const struct blk_crypto_key *bkey,
 			   const union cqhci_crypto_cfg_entry *cfg, int slot);
 #endif
 	void (*set_tran_desc)(struct cqhci_host *cq_host, u8 **desc,
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index e113b99a3eab..f661d855b77e 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -1859,6 +1859,7 @@ static __maybe_unused int sdhci_msm_ice_suspend(struct sdhci_msm_host *msm_host)
  * vendor-specific SCM calls for this; it doesn't support the standard way.
  */
 static int sdhci_msm_program_key(struct cqhci_host *cq_host,
+				 const struct blk_crypto_key *bkey,
 				 const union cqhci_crypto_cfg_entry *cfg,
 				 int slot)
 {
@@ -1866,6 +1867,7 @@ static int sdhci_msm_program_key(struct cqhci_host *cq_host,
 	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 	struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
 	union cqhci_crypto_cap_entry cap;
+	u8 ice_key_size;
 
 	/* Only AES-256-XTS has been tested so far. */
 	cap = cq_host->crypto_cap_array[cfg->crypto_cap_idx];
@@ -1873,11 +1875,11 @@ static int sdhci_msm_program_key(struct cqhci_host *cq_host,
 		cap.key_size != CQHCI_CRYPTO_KEY_SIZE_256)
 		return -EINVAL;
 
+	ice_key_size = QCOM_ICE_CRYPTO_KEY_SIZE_256;
 	if (cfg->config_enable & CQHCI_CRYPTO_CONFIGURATION_ENABLE)
 		return qcom_ice_program_key(msm_host->ice,
 					    QCOM_ICE_CRYPTO_ALG_AES_XTS,
-					    QCOM_ICE_CRYPTO_KEY_SIZE_256,
-					    cfg->crypto_key,
+					    ice_key_size, bkey,
 					    cfg->data_unit_size, slot);
 	else
 		return qcom_ice_evict_key(msm_host->ice, slot);
diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index fbab7fe5c652..6f941d32fffb 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -163,8 +163,8 @@ EXPORT_SYMBOL_GPL(qcom_ice_suspend);
 
 int qcom_ice_program_key(struct qcom_ice *ice,
 			 u8 algorithm_id, u8 key_size,
-			 const u8 crypto_key[], u8 data_unit_size,
-			 int slot)
+			 const struct blk_crypto_key *bkey,
+			 u8 data_unit_size, int slot)
 {
 	struct device *dev = ice->dev;
 	union {
@@ -183,7 +183,7 @@ int qcom_ice_program_key(struct qcom_ice *ice,
 		return -EINVAL;
 	}
 
-	memcpy(key.bytes, crypto_key, AES_256_XTS_KEY_SIZE);
+	memcpy(key.bytes, bkey->raw, AES_256_XTS_KEY_SIZE);
 
 	/* The SCM call requires that the key words are encoded in big endian */
 	for (i = 0; i < ARRAY_SIZE(key.words); i++)
diff --git a/drivers/ufs/core/ufshcd-crypto.c b/drivers/ufs/core/ufshcd-crypto.c
index f4cc54d82281..34537cbac622 100644
--- a/drivers/ufs/core/ufshcd-crypto.c
+++ b/drivers/ufs/core/ufshcd-crypto.c
@@ -18,6 +18,7 @@ static const struct ufs_crypto_alg_entry {
 };
 
 static int ufshcd_program_key(struct ufs_hba *hba,
+			      const struct blk_crypto_key *bkey,
 			      const union ufs_crypto_cfg_entry *cfg, int slot)
 {
 	int i;
@@ -27,7 +28,7 @@ static int ufshcd_program_key(struct ufs_hba *hba,
 	ufshcd_hold(hba);
 
 	if (hba->vops && hba->vops->program_key) {
-		err = hba->vops->program_key(hba, cfg, slot);
+		err = hba->vops->program_key(hba, bkey, cfg, slot);
 		goto out;
 	}
 
@@ -89,7 +90,7 @@ static int ufshcd_crypto_keyslot_program(struct blk_crypto_profile *profile,
 		memcpy(cfg.crypto_key, key->raw, key->size);
 	}
 
-	err = ufshcd_program_key(hba, &cfg, slot);
+	err = ufshcd_program_key(hba, key, &cfg, slot);
 
 	memzero_explicit(&cfg, sizeof(cfg));
 	return err;
@@ -103,7 +104,7 @@ static int ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
 	 */
 	union ufs_crypto_cfg_entry cfg = {};
 
-	return ufshcd_program_key(hba, &cfg, slot);
+	return ufshcd_program_key(hba, NULL, &cfg, slot);
 }
 
 static int ufshcd_crypto_keyslot_evict(struct blk_crypto_profile *profile,
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index cca190d1c577..82584bb318fb 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -150,6 +150,7 @@ static inline int ufs_qcom_ice_suspend(struct ufs_qcom_host *host)
 }
 
 static int ufs_qcom_ice_program_key(struct ufs_hba *hba,
+				    const struct blk_crypto_key *bkey,
 				    const union ufs_crypto_cfg_entry *cfg,
 				    int slot)
 {
@@ -157,6 +158,7 @@ static int ufs_qcom_ice_program_key(struct ufs_hba *hba,
 	union ufs_crypto_cap_entry cap;
 	bool config_enable =
 		cfg->config_enable & UFS_CRYPTO_CONFIGURATION_ENABLE;
+	u8 ice_key_size;
 
 	/* Only AES-256-XTS has been tested so far. */
 	cap = hba->crypto_cap_array[cfg->crypto_cap_idx];
@@ -164,11 +166,11 @@ static int ufs_qcom_ice_program_key(struct ufs_hba *hba,
 	    cap.key_size != UFS_CRYPTO_KEY_SIZE_256)
 		return -EOPNOTSUPP;
 
+	ice_key_size = QCOM_ICE_CRYPTO_KEY_SIZE_256;
 	if (config_enable)
 		return qcom_ice_program_key(host->ice,
 					    QCOM_ICE_CRYPTO_ALG_AES_XTS,
-					    QCOM_ICE_CRYPTO_KEY_SIZE_256,
-					    cfg->crypto_key,
+					    ice_key_size, bkey,
 					    cfg->data_unit_size, slot);
 	else
 		return qcom_ice_evict_key(host->ice, slot);
diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
index 5870a94599a2..9dd835dba2a7 100644
--- a/include/soc/qcom/ice.h
+++ b/include/soc/qcom/ice.h
@@ -7,6 +7,7 @@
 #define __QCOM_ICE_H__
 
 #include <linux/types.h>
+#include <linux/blk-crypto.h>
 
 struct qcom_ice;
 
@@ -30,8 +31,8 @@ int qcom_ice_resume(struct qcom_ice *ice);
 int qcom_ice_suspend(struct qcom_ice *ice);
 int qcom_ice_program_key(struct qcom_ice *ice,
 			 u8 algorithm_id, u8 key_size,
-			 const u8 crypto_key[], u8 data_unit_size,
-			 int slot);
+			 const struct blk_crypto_key *bkey,
+			 u8 data_unit_size, int slot);
 int qcom_ice_evict_key(struct qcom_ice *ice, int slot);
 struct qcom_ice *of_qcom_ice_get(struct device *dev);
 #endif /* __QCOM_ICE_H__ */
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index df68fb1d4f3f..0c784f0ee836 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -366,6 +366,7 @@ struct ufs_hba_variant_ops {
 				struct devfreq_dev_profile *profile,
 				struct devfreq_simple_ondemand_data *data);
 	int	(*program_key)(struct ufs_hba *hba,
+			       const struct blk_crypto_key *bkey,
 			       const union ufs_crypto_cfg_entry *cfg, int slot);
 	void	(*event_notify)(struct ufs_hba *hba,
 				enum ufs_event_type evt, void *data);
-- 
2.43.0

[PATCH v5 02/15] qcom_scm: scm call for deriving a software secret

[Gaurav Kashyap]

Inline storage encryption may require deriving a software
secret from storage keys added to the kernel.

For non-wrapped keys, this can be directly done in the kernel as
keys are in the clear.

However, hardware wrapped keys can only be unwrapped by the wrapping
entity. In case of Qualcomm's wrapped key solution, this is done by
the Hardware Key Manager (HWKM) from Trustzone.
Hence, adding a new SCM call which in the end provides a hook
to the software secret crypto profile API provided by the block
layer.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/firmware/qcom/qcom_scm.c       | 65 ++++++++++++++++++++++++++
 drivers/firmware/qcom/qcom_scm.h       |  1 +
 include/linux/firmware/qcom/qcom_scm.h |  2 +
 3 files changed, 68 insertions(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index e528c620c7b8..8f23b459c525 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -1244,6 +1244,71 @@ int qcom_scm_ice_set_key(u32 index, const u8 *key, u32 key_size,
 }
 EXPORT_SYMBOL_GPL(qcom_scm_ice_set_key);
 
+/**
+ * qcom_scm_derive_sw_secret() - Derive software secret from wrapped key
+ * @wkey: the hardware wrapped key inaccessible to software
+ * @wkey_size: size of the wrapped key
+ * @sw_secret: the secret to be derived which is exactly the secret size
+ * @sw_secret_size: size of the sw_secret
+ *
+ * Derive a software secret from a hardware wrapped key for software crypto
+ * operations.
+ * For wrapped keys, the key needs to be unwrapped, in order to derive a
+ * software secret, which can be done in the hardware from a secure execution
+ * environment.
+ *
+ * For more information on sw secret, please refer to "Hardware-wrapped keys"
+ * section of Documentation/block/inline-encryption.rst.
+ *
+ * Return: 0 on success; -errno on failure.
+ */
+int qcom_scm_derive_sw_secret(const u8 *wkey, size_t wkey_size,
+			      u8 *sw_secret, size_t sw_secret_size)
+{
+	struct qcom_scm_desc desc = {
+		.svc = QCOM_SCM_SVC_ES,
+		.cmd =  QCOM_SCM_ES_DERIVE_SW_SECRET,
+		.arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_RW,
+					 QCOM_SCM_VAL, QCOM_SCM_RW,
+					 QCOM_SCM_VAL),
+		.args[1] = wkey_size,
+		.args[3] = sw_secret_size,
+		.owner = ARM_SMCCC_OWNER_SIP,
+	};
+
+	int ret;
+
+	void *wkey_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
+							    wkey_size,
+							    GFP_KERNEL);
+	if (!wkey_buf)
+		return -ENOMEM;
+
+	void *secret_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
+							       sw_secret_size,
+							       GFP_KERNEL);
+	if (!secret_buf) {
+		ret = -ENOMEM;
+		goto out_free_wrapped;
+	}
+
+	memcpy(wkey_buf, wkey, wkey_size);
+	desc.args[0] = qcom_tzmem_to_phys(wkey_buf);
+	desc.args[2] = qcom_tzmem_to_phys(secret_buf);
+
+	ret = qcom_scm_call(__scm->dev, &desc, NULL);
+	if (!ret)
+		memcpy(sw_secret, secret_buf, sw_secret_size);
+
+	memzero_explicit(secret_buf, sw_secret_size);
+
+out_free_wrapped:
+	memzero_explicit(wkey_buf, wkey_size);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(qcom_scm_derive_sw_secret);
+
 /**
  * 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 cb7273aa0a5e..56ff0806f5d2 100644
--- a/drivers/firmware/qcom/qcom_scm.h
+++ b/drivers/firmware/qcom/qcom_scm.h
@@ -127,6 +127,7 @@ struct qcom_tzmem_pool *qcom_scm_get_tzmem_pool(void);
 #define QCOM_SCM_SVC_ES			0x10	/* Enterprise Security */
 #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_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 767bffe20766..ce343e102c84 100644
--- a/include/linux/firmware/qcom/qcom_scm.h
+++ b/include/linux/firmware/qcom/qcom_scm.h
@@ -103,6 +103,8 @@ bool qcom_scm_ice_available(void);
 int qcom_scm_ice_invalidate_key(u32 index);
 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);
 
 bool qcom_scm_hdcp_available(void);
 int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp);
-- 
2.43.0

[PATCH v5 03/15] qcom_scm: scm call for create, prepare and import keys

[Gaurav Kashyap]

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.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/firmware/qcom/qcom_scm.c       | 175 +++++++++++++++++++++++++
 drivers/firmware/qcom/qcom_scm.h       |   3 +
 include/linux/firmware/qcom/qcom_scm.h |   5 +
 3 files changed, 183 insertions(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 8f23b459c525..61a1ace3c683 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -1309,6 +1309,181 @@ 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: 0 on success; -errno on failure.
+ */
+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,
+	};
+
+	int ret;
+
+	void *lt_key_buf __free(qcom_tzmem) = 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);
+
+	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: 0 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,
+	};
+
+	int ret;
+
+	void *lt_key_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
+							       lt_key_size,
+							       GFP_KERNEL);
+	if (!lt_key_buf)
+		return -ENOMEM;
+
+	void *eph_key_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
+								eph_key_size,
+								GFP_KERNEL);
+	if (!eph_key_buf) {
+		ret = -ENOMEM;
+		goto out_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);
+
+out_free_longterm:
+	memzero_explicit(lt_key_buf, lt_key_size);
+
+	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: 0 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,
+	};
+
+	int ret;
+
+	void *imp_key_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
+								imp_key_size,
+								GFP_KERNEL);
+	if (!imp_key_buf)
+		return -ENOMEM;
+
+	void *lt_key_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
+							       lt_key_size,
+							       GFP_KERNEL);
+	if (!lt_key_buf) {
+		ret = -ENOMEM;
+		goto out_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);
+
+out_free_longterm:
+	memzero_explicit(imp_key_buf, imp_key_size);
+
+	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 ce343e102c84..665ea8f0e8bb 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);
-- 
2.43.0

[PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap]

Qualcomm's ICE (Inline Crypto Engine) contains a proprietary
key management hardware called Hardware Key Manager (HWKM).
This patch integrates HWKM support in ICE when it is
available. HWKM primarily provides hardware wrapped key support
where the ICE (storage) keys are not available in software and
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, standard keys have
to be used without using HWKM. Hence, providing a toggle controlled
by a devicetree entry to use HWKM or not.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/soc/qcom/ice.c | 153 +++++++++++++++++++++++++++++++++++++++--
 include/soc/qcom/ice.h |   1 +
 2 files changed, 150 insertions(+), 4 deletions(-)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index 6f941d32fffb..d5e74cf2946b 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -26,6 +26,40 @@
 #define QCOM_ICE_REG_FUSE_SETTING		0x0010
 #define QCOM_ICE_REG_BIST_STATUS		0x0070
 #define QCOM_ICE_REG_ADVANCED_CONTROL		0x1000
+#define QCOM_ICE_REG_CONTROL			0x0
+/* QCOM ICE HWKM registers */
+#define QCOM_ICE_REG_HWKM_TZ_KM_CTL			0x1000
+#define QCOM_ICE_REG_HWKM_TZ_KM_STATUS			0x1004
+#define QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS	0x2008
+#define QCOM_ICE_REG_HWKM_BANK0_BBAC_0			0x5000
+#define QCOM_ICE_REG_HWKM_BANK0_BBAC_1			0x5004
+#define QCOM_ICE_REG_HWKM_BANK0_BBAC_2			0x5008
+#define QCOM_ICE_REG_HWKM_BANK0_BBAC_3			0x500C
+#define QCOM_ICE_REG_HWKM_BANK0_BBAC_4			0x5010
+
+/* QCOM ICE HWKM reg vals */
+#define QCOM_ICE_HWKM_BIST_DONE_V1		BIT(16)
+#define QCOM_ICE_HWKM_BIST_DONE_V2		BIT(9)
+#define QCOM_ICE_HWKM_BIST_DONE(ver)		QCOM_ICE_HWKM_BIST_DONE_V##ver
+
+#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V1		BIT(14)
+#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V2		BIT(7)
+#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v)		QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V##v
+
+#define QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE		BIT(2)
+#define QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE		BIT(1)
+#define QCOM_ICE_HWKM_KT_CLEAR_DONE			BIT(0)
+
+#define QCOM_ICE_HWKM_BIST_VAL(v)	(QCOM_ICE_HWKM_BIST_DONE(v) |		\
+					QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v) |	\
+					QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE |	\
+					QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE |	\
+					QCOM_ICE_HWKM_KT_CLEAR_DONE)
+
+#define QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL	(BIT(0) | BIT(1) | BIT(2))
+#define QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK	GENMASK(31, 1)
+#define QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL	(BIT(1) | BIT(2))
+#define QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL	BIT(3)
 
 /* BIST ("built-in self-test") status flags */
 #define QCOM_ICE_BIST_STATUS_MASK		GENMASK(31, 28)
@@ -34,6 +68,9 @@
 #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK	0x2
 #define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK	0x4
 
+#define QCOM_ICE_HWKM_REG_OFFSET	0x8000
+#define HWKM_OFFSET(reg)		((reg) + QCOM_ICE_HWKM_REG_OFFSET)
+
 #define qcom_ice_writel(engine, val, reg)	\
 	writel((val), (engine)->base + (reg))
 
@@ -46,6 +83,9 @@ struct qcom_ice {
 	struct device_link *link;
 
 	struct clk *core_clk;
+	u8 hwkm_version;
+	bool use_hwkm;
+	bool hwkm_init_complete;
 };
 
 static bool qcom_ice_check_supported(struct qcom_ice *ice)
@@ -63,8 +103,21 @@ static bool qcom_ice_check_supported(struct qcom_ice *ice)
 		return false;
 	}
 
-	dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
-		 major, minor, step);
+	if (major >= 4 || (major == 3 && minor == 2 && step >= 1))
+		ice->hwkm_version = 2;
+	else if (major == 3 && minor == 2)
+		ice->hwkm_version = 1;
+	else
+		ice->hwkm_version = 0;
+
+	if (ice->hwkm_version == 0)
+		ice->use_hwkm = false;
+
+	dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d, HWKM v%d\n",
+		 major, minor, step, ice->hwkm_version);
+
+	if (!ice->use_hwkm)
+		dev_info(dev, "QC ICE HWKM (Hardware Key Manager) not used/supported");
 
 	/* If fuses are blown, ICE might not work in the standard way. */
 	regval = qcom_ice_readl(ice, QCOM_ICE_REG_FUSE_SETTING);
@@ -113,27 +166,106 @@ static void qcom_ice_optimization_enable(struct qcom_ice *ice)
  * fails, so we needn't do it in software too, and (c) properly testing
  * storage encryption requires testing the full storage stack anyway,
  * and not relying on hardware-level self-tests.
+ *
+ * However, we still care about if HWKM BIST failed (when supported) as
+ * important functionality would fail later, so disable hwkm on failure.
  */
 static int qcom_ice_wait_bist_status(struct qcom_ice *ice)
 {
 	u32 regval;
+	u32 bist_done_val;
 	int err;
 
 	err = readl_poll_timeout(ice->base + QCOM_ICE_REG_BIST_STATUS,
 				 regval, !(regval & QCOM_ICE_BIST_STATUS_MASK),
 				 50, 5000);
-	if (err)
+	if (err) {
 		dev_err(ice->dev, "Timed out waiting for ICE self-test to complete\n");
+		return err;
+	}
 
+	if (ice->use_hwkm) {
+		bist_done_val = ice->hwkm_version == 1 ?
+				QCOM_ICE_HWKM_BIST_VAL(1) :
+				QCOM_ICE_HWKM_BIST_VAL(2);
+		if (qcom_ice_readl(ice,
+				   HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_STATUS)) !=
+				   bist_done_val) {
+			dev_err(ice->dev, "HWKM BIST error\n");
+			ice->use_hwkm = false;
+			err = -ENODEV;
+		}
+	}
 	return err;
 }
 
+static void qcom_ice_enable_standard_mode(struct qcom_ice *ice)
+{
+	u32 val = 0;
+
+	/*
+	 * When ICE is in standard (hwkm) mode, it supports HW wrapped
+	 * keys, and when it is in legacy mode, it only supports standard
+	 * (non HW wrapped) keys.
+	 *
+	 * Put ICE in standard mode, ICE defaults to legacy mode.
+	 * Legacy mode - ICE HWKM slave not supported.
+	 * Standard mode - ICE HWKM slave supported.
+	 *
+	 * Depending on the version of HWKM, it is controlled by different
+	 * registers in ICE.
+	 */
+	if (ice->hwkm_version >= 2) {
+		val = qcom_ice_readl(ice, QCOM_ICE_REG_CONTROL);
+		val = val & QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK;
+		qcom_ice_writel(ice, val, QCOM_ICE_REG_CONTROL);
+	} else {
+		qcom_ice_writel(ice, QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL,
+				HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_CTL));
+	}
+}
+
+static void qcom_ice_hwkm_init(struct qcom_ice *ice)
+{
+	/* Disable CRC checks. This HWKM feature is not used. */
+	qcom_ice_writel(ice, QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL,
+			HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_CTL));
+
+	/*
+	 * Give register bank of the HWKM slave access to read and modify
+	 * the keyslots in ICE HWKM slave. Without this, trustzone will not
+	 * be able to program keys into ICE.
+	 */
+	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_0));
+	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_1));
+	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_2));
+	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_3));
+	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_4));
+
+	/* Clear HWKM response FIFO before doing anything */
+	qcom_ice_writel(ice, QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL,
+			HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS));
+	ice->hwkm_init_complete = true;
+}
+
 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);
 
@@ -149,6 +281,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);
@@ -156,6 +292,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;
 }
@@ -205,6 +342,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)
 {
@@ -239,6 +382,8 @@ 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 = of_property_read_bool(dev->of_node,
+						 "qcom,ice-use-hwkm");
 
 	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

[PATCH v5 05/15] soc: qcom: ice: support for hardware wrapped keys

[Gaurav Kashyap]

Now that HWKM support is added to ICE, extend the ICE
driver to support hardware wrapped keys programming coming
in from the storage controllers (ufs and emmc). This is
similar to standard keys where the call is forwarded to
Trustzone, however certain wrapped key and HWKM specific
actions has to be performed around the SCM calls.

Derive software secret support is also added by forwarding the
call to the corresponding scm api.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/soc/qcom/ice.c | 119 +++++++++++++++++++++++++++++++++++++----
 include/soc/qcom/ice.h |   4 ++
 2 files changed, 112 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index d5e74cf2946b..f0e9e0885732 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -27,6 +27,8 @@
 #define QCOM_ICE_REG_BIST_STATUS		0x0070
 #define QCOM_ICE_REG_ADVANCED_CONTROL		0x1000
 #define QCOM_ICE_REG_CONTROL			0x0
+#define QCOM_ICE_LUT_KEYS_CRYPTOCFG_R16		0x4040
+
 /* QCOM ICE HWKM registers */
 #define QCOM_ICE_REG_HWKM_TZ_KM_CTL			0x1000
 #define QCOM_ICE_REG_HWKM_TZ_KM_STATUS			0x1004
@@ -68,6 +70,8 @@
 #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK	0x2
 #define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK	0x4
 
+#define QCOM_ICE_LUT_KEYS_CRYPTOCFG_OFFSET	0x80
+
 #define QCOM_ICE_HWKM_REG_OFFSET	0x8000
 #define HWKM_OFFSET(reg)		((reg) + QCOM_ICE_HWKM_REG_OFFSET)
 
@@ -88,6 +92,16 @@ struct qcom_ice {
 	bool hwkm_init_complete;
 };
 
+union crypto_cfg {
+	__le32 regval;
+	struct {
+		u8 dusize;
+		u8 capidx;
+		u8 reserved;
+		u8 cfge;
+	};
+};
+
 static bool qcom_ice_check_supported(struct qcom_ice *ice)
 {
 	u32 regval = qcom_ice_readl(ice, QCOM_ICE_REG_VERSION);
@@ -298,6 +312,51 @@ int qcom_ice_suspend(struct qcom_ice *ice)
 }
 EXPORT_SYMBOL_GPL(qcom_ice_suspend);
 
+/*
+ * HW dictates the internal mapping between the ICE and HWKM slots,
+ * which are different for different versions, make the translation
+ * here. For v1 however, the translation is done in trustzone.
+ */
+static int translate_hwkm_slot(struct qcom_ice *ice, int slot)
+{
+	return (ice->hwkm_version == 1) ? slot : (slot * 2);
+}
+
+static int qcom_ice_program_wrapped_key(struct qcom_ice *ice,
+					const struct blk_crypto_key *key,
+					u8 data_unit_size, int slot)
+{
+	union crypto_cfg cfg;
+	int hwkm_slot;
+	int err;
+
+	hwkm_slot = translate_hwkm_slot(ice, slot);
+
+	memset(&cfg, 0, sizeof(cfg));
+	cfg.dusize = data_unit_size;
+	cfg.capidx = QCOM_SCM_ICE_CIPHER_AES_256_XTS;
+	cfg.cfge = 0x80;
+
+	/* Clear CFGE */
+	qcom_ice_writel(ice, 0x0, QCOM_ICE_LUT_KEYS_CRYPTOCFG_R16 +
+				  QCOM_ICE_LUT_KEYS_CRYPTOCFG_OFFSET * slot);
+
+	/* Call trustzone to program the wrapped key using hwkm */
+	err = qcom_scm_ice_set_key(hwkm_slot, key->raw, key->size,
+				   QCOM_SCM_ICE_CIPHER_AES_256_XTS, data_unit_size);
+	if (err) {
+		pr_err("%s:SCM call Error: 0x%x slot %d\n", __func__, err,
+		       slot);
+		return err;
+	}
+
+	/* Enable CFGE after programming key */
+	qcom_ice_writel(ice, cfg.regval, QCOM_ICE_LUT_KEYS_CRYPTOCFG_R16 +
+					 QCOM_ICE_LUT_KEYS_CRYPTOCFG_OFFSET * slot);
+
+	return err;
+}
+
 int qcom_ice_program_key(struct qcom_ice *ice,
 			 u8 algorithm_id, u8 key_size,
 			 const struct blk_crypto_key *bkey,
@@ -313,24 +372,39 @@ int qcom_ice_program_key(struct qcom_ice *ice,
 
 	/* Only AES-256-XTS has been tested so far. */
 	if (algorithm_id != QCOM_ICE_CRYPTO_ALG_AES_XTS ||
-	    key_size != QCOM_ICE_CRYPTO_KEY_SIZE_256) {
+	    (key_size != QCOM_ICE_CRYPTO_KEY_SIZE_256 &&
+	    key_size != QCOM_ICE_CRYPTO_KEY_SIZE_WRAPPED)) {
 		dev_err_ratelimited(dev,
 				    "Unhandled crypto capability; algorithm_id=%d, key_size=%d\n",
 				    algorithm_id, key_size);
 		return -EINVAL;
 	}
 
-	memcpy(key.bytes, bkey->raw, AES_256_XTS_KEY_SIZE);
-
-	/* The SCM call requires that the key words are encoded in big endian */
-	for (i = 0; i < ARRAY_SIZE(key.words); i++)
-		__cpu_to_be32s(&key.words[i]);
+	if (bkey->crypto_cfg.key_type == BLK_CRYPTO_KEY_TYPE_HW_WRAPPED) {
+		/* It is expected that HWKM init has completed before programming wrapped keys */
+		if (!ice->use_hwkm || !ice->hwkm_init_complete) {
+			dev_err_ratelimited(dev, "HWKM not currently used or initialized\n");
+			return -EINVAL;
+		}
+		err = qcom_ice_program_wrapped_key(ice, bkey, data_unit_size,
+						   slot);
+	} else {
+		if (bkey->size != QCOM_ICE_CRYPTO_KEY_SIZE_256)
+			dev_err_ratelimited(dev,
+					    "Incorrect key size; bkey->size=%d\n",
+					    algorithm_id);
+		return -EINVAL;
+		memcpy(key.bytes, bkey->raw, AES_256_XTS_KEY_SIZE);
 
-	err = qcom_scm_ice_set_key(slot, key.bytes, AES_256_XTS_KEY_SIZE,
-				   QCOM_SCM_ICE_CIPHER_AES_256_XTS,
-				   data_unit_size);
+		/* The SCM call requires that the key words are encoded in big endian */
+		for (i = 0; i < ARRAY_SIZE(key.words); i++)
+			__cpu_to_be32s(&key.words[i]);
 
-	memzero_explicit(&key, sizeof(key));
+		err = qcom_scm_ice_set_key(slot, key.bytes, AES_256_XTS_KEY_SIZE,
+					   QCOM_SCM_ICE_CIPHER_AES_256_XTS,
+					   data_unit_size);
+		memzero_explicit(&key, sizeof(key));
+	}
 
 	return err;
 }
@@ -338,7 +412,21 @@ EXPORT_SYMBOL_GPL(qcom_ice_program_key);
 
 int qcom_ice_evict_key(struct qcom_ice *ice, int slot)
 {
-	return qcom_scm_ice_invalidate_key(slot);
+	int hwkm_slot = slot;
+
+	if (ice->use_hwkm) {
+		hwkm_slot = translate_hwkm_slot(ice, slot);
+	/*
+	 * Ignore calls to evict key when HWKM is supported and hwkm init
+	 * is not yet done. This is to avoid the clearing all slots call
+	 * during a storage reset when ICE is still in legacy mode. HWKM slave
+	 * in ICE takes care of zeroing out the keytable on reset.
+	 */
+		if (!ice->hwkm_init_complete)
+			return 0;
+	}
+
+	return qcom_scm_ice_invalidate_key(hwkm_slot);
 }
 EXPORT_SYMBOL_GPL(qcom_ice_evict_key);
 
@@ -348,6 +436,15 @@ bool qcom_ice_hwkm_supported(struct qcom_ice *ice)
 }
 EXPORT_SYMBOL_GPL(qcom_ice_hwkm_supported);
 
+int qcom_ice_derive_sw_secret(struct qcom_ice *ice, const u8 wkey[],
+			      unsigned int wkey_size,
+			      u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE])
+{
+	return qcom_scm_derive_sw_secret(wkey, wkey_size,
+					 sw_secret, BLK_CRYPTO_SW_SECRET_SIZE);
+}
+EXPORT_SYMBOL_GPL(qcom_ice_derive_sw_secret);
+
 static struct qcom_ice *qcom_ice_create(struct device *dev,
 					void __iomem *base)
 {
diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
index 1f52e82e3e1c..dabe0d3a1fd0 100644
--- a/include/soc/qcom/ice.h
+++ b/include/soc/qcom/ice.h
@@ -17,6 +17,7 @@ enum qcom_ice_crypto_key_size {
 	QCOM_ICE_CRYPTO_KEY_SIZE_192		= 0x2,
 	QCOM_ICE_CRYPTO_KEY_SIZE_256		= 0x3,
 	QCOM_ICE_CRYPTO_KEY_SIZE_512		= 0x4,
+	QCOM_ICE_CRYPTO_KEY_SIZE_WRAPPED	= 0x5,
 };
 
 enum qcom_ice_crypto_alg {
@@ -35,5 +36,8 @@ int qcom_ice_program_key(struct qcom_ice *ice,
 			 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);
+int qcom_ice_derive_sw_secret(struct qcom_ice *ice, const u8 wkey[],
+			      unsigned int wkey_size,
+			      u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]);
 struct qcom_ice *of_qcom_ice_get(struct device *dev);
 #endif /* __QCOM_ICE_H__ */
-- 
2.43.0

[PATCH v5 06/15] soc: qcom: ice: support for generate, import and prepare key

[Gaurav Kashyap]

Wrapped key creation and management using HWKM is currently
supported only through Qualcomm's Trustzone.
Three new SCM calls have already been added in the scm layer
for this purpose.

This patch adds support for generate, prepare and import key
apis in ICE module and hooks it up the scm calls defined for them.
This will eventually plug into the new IOCTLS added for this
usecase in the block layer.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/soc/qcom/ice.c | 75 ++++++++++++++++++++++++++++++++++++++++++
 include/soc/qcom/ice.h |  8 +++++
 2 files changed, 83 insertions(+)

diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
index f0e9e0885732..68062b27f40c 100644
--- a/drivers/soc/qcom/ice.c
+++ b/drivers/soc/qcom/ice.c
@@ -21,6 +21,13 @@
 
 #define AES_256_XTS_KEY_SIZE			64
 
+/*
+ * Wrapped key sizes that HWKM expects and manages is different for different
+ * versions of the hardware.
+ */
+#define QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(v)	\
+	((v) == 1 ? 68 : 100)
+
 /* QCOM ICE registers */
 #define QCOM_ICE_REG_VERSION			0x0008
 #define QCOM_ICE_REG_FUSE_SETTING		0x0010
@@ -445,6 +452,74 @@ int qcom_ice_derive_sw_secret(struct qcom_ice *ice, const u8 wkey[],
 }
 EXPORT_SYMBOL_GPL(qcom_ice_derive_sw_secret);
 
+/**
+ * qcom_ice_generate_key() - Generate a wrapped key for inline encryption
+ * @lt_key: longterm wrapped key that is generated, which is
+ *          BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE in size.
+ *
+ * Make a scm call into trustzone to generate a wrapped key for storage
+ * encryption using hwkm.
+ *
+ * Return: lt wrapped key size on success; err on failure.
+ */
+int qcom_ice_generate_key(struct qcom_ice *ice,
+			  u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	size_t wk_size = QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(ice->hwkm_version);
+
+	if (!qcom_scm_generate_ice_key(lt_key, wk_size))
+		return wk_size;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_ice_generate_key);
+
+/**
+ * qcom_ice_prepare_key() - Prepare a longterm wrapped key for inline encryption
+ * @lt_key: longterm wrapped key that is generated or imported.
+ * @lt_key_size: size of the longterm wrapped_key
+ * @eph_key: wrapped key returned which has been wrapped with a per-boot ephemeral key,
+ *           size of which is BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE in size.
+ *
+ * Make a scm call into trustzone to prepare a wrapped key for storage
+ * encryption by rewrapping the longterm wrapped key with a per boot ephemeral
+ * key using hwkm.
+ *
+ * Return: eph wrapped key size on success; err on failure.
+ */
+int qcom_ice_prepare_key(struct qcom_ice *ice, const u8 *lt_key, size_t lt_key_size,
+			 u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	size_t wk_size = QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(ice->hwkm_version);
+
+	if (!qcom_scm_prepare_ice_key(lt_key, lt_key_size, eph_key, wk_size))
+		return wk_size;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_ice_prepare_key);
+
+/**
+ * qcom_ice_import_key() - Import a raw key for inline encryption
+ * @imp_key: raw key that has to be imported
+ * @imp_key_size: size of the imported key
+ * @lt_key: longterm wrapped key that is imported, which is
+ *          BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE in size.
+ *
+ * Make a scm call into trustzone to import a raw key for storage encryption
+ * and generate a longterm wrapped key using hwkm.
+ *
+ * Return: lt wrapped key size on success; err on failure.
+ */
+int qcom_ice_import_key(struct qcom_ice *ice, const u8 *imp_key, size_t imp_key_size,
+			u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	size_t wk_size = QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(ice->hwkm_version);
+
+	if (!qcom_scm_import_ice_key(imp_key, imp_key_size, lt_key, wk_size))
+		return wk_size;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_ice_import_key);
+
 static struct qcom_ice *qcom_ice_create(struct device *dev,
 					void __iomem *base)
 {
diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
index dabe0d3a1fd0..dcf277d196ff 100644
--- a/include/soc/qcom/ice.h
+++ b/include/soc/qcom/ice.h
@@ -39,5 +39,13 @@ bool qcom_ice_hwkm_supported(struct qcom_ice *ice);
 int qcom_ice_derive_sw_secret(struct qcom_ice *ice, const u8 wkey[],
 			      unsigned int wkey_size,
 			      u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]);
+int qcom_ice_generate_key(struct qcom_ice *ice,
+			  u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
+int qcom_ice_prepare_key(struct qcom_ice *ice,
+			 const u8 *lt_key, size_t lt_key_size,
+			 u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
+int qcom_ice_import_key(struct qcom_ice *ice,
+			const u8 *imp_key, size_t imp_key_size,
+			u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
 struct qcom_ice *of_qcom_ice_get(struct device *dev);
 #endif /* __QCOM_ICE_H__ */
-- 
2.43.0

[PATCH v5 07/15] ufs: core: support wrapped keys in ufs core

[Gaurav Kashyap]

Since wrapped keys are not part of the UFS specifications,
it needs to be treated as a supported quirk of the UFS
controller. This way, based on the quirk set during a host
probe, UFS crypto can choose to register either standard or
wrapped keys with block crypto profile.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/ufs/core/ufshcd-crypto.c | 24 ++++++++++++++++--------
 include/ufs/ufshcd.h             |  6 ++++++
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/ufs/core/ufshcd-crypto.c b/drivers/ufs/core/ufshcd-crypto.c
index 34537cbac622..399b55d67b3b 100644
--- a/drivers/ufs/core/ufshcd-crypto.c
+++ b/drivers/ufs/core/ufshcd-crypto.c
@@ -81,13 +81,15 @@ static int ufshcd_crypto_keyslot_program(struct blk_crypto_profile *profile,
 	cfg.crypto_cap_idx = cap_idx;
 	cfg.config_enable = UFS_CRYPTO_CONFIGURATION_ENABLE;
 
-	if (ccap_array[cap_idx].algorithm_id == UFS_CRYPTO_ALG_AES_XTS) {
-		/* In XTS mode, the blk_crypto_key's size is already doubled */
-		memcpy(cfg.crypto_key, key->raw, key->size/2);
-		memcpy(cfg.crypto_key + UFS_CRYPTO_KEY_MAX_SIZE/2,
-		       key->raw + key->size/2, key->size/2);
-	} else {
-		memcpy(cfg.crypto_key, key->raw, key->size);
+	if (key->crypto_cfg.key_type != BLK_CRYPTO_KEY_TYPE_HW_WRAPPED) {
+		if (ccap_array[cap_idx].algorithm_id == UFS_CRYPTO_ALG_AES_XTS) {
+			/* In XTS mode, the blk_crypto_key's size is already doubled */
+			memcpy(cfg.crypto_key, key->raw, key->size / 2);
+			memcpy(cfg.crypto_key + UFS_CRYPTO_KEY_MAX_SIZE / 2,
+			       key->raw + key->size / 2, key->size / 2);
+		} else {
+			memcpy(cfg.crypto_key, key->raw, key->size);
+		}
 	}
 
 	err = ufshcd_program_key(hba, key, &cfg, slot);
@@ -191,7 +193,13 @@ 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->quirks & UFSHCD_QUIRK_USES_WRAPPED_CRYPTO_KEYS)
+		hba->crypto_profile.key_types_supported =
+				BLK_CRYPTO_KEY_TYPE_HW_WRAPPED;
+	else
+		hba->crypto_profile.key_types_supported =
+				BLK_CRYPTO_KEY_TYPE_STANDARD;
+
 	hba->crypto_profile.dev = hba->dev;
 
 	/*
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 0c784f0ee836..927db0091722 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -646,6 +646,12 @@ enum ufshcd_quirks {
 	 * thus need this quirk to skip related flow.
 	 */
 	UFSHCD_QUIRK_MCQ_BROKEN_RTC			= 1 << 21,
+
+	/*
+	 * This quirk indicates that UFS will be using HW wrapped keys
+	 * when using inline encryption.
+	 */
+	UFSHCD_QUIRK_USES_WRAPPED_CRYPTO_KEYS		= 1 << 22,
 };
 
 enum ufshcd_caps {
-- 
2.43.0

[PATCH v5 08/15] ufs: core: add support to derive software secret

[Gaurav Kashyap]

Block crypto allows storage controllers like UFS to
register an op derive a software secret from wrapped
keys added to the kernel.

Wrapped keys in most cases will have vendor specific
implementations, which means this op would need to have
a corresponding UFS variant op.
This change adds hooks in UFS core to support this variant
ops and tie them to the blk crypto op.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/ufs/core/ufshcd-crypto.c | 15 +++++++++++++++
 include/ufs/ufshcd.h             |  4 ++++
 2 files changed, 19 insertions(+)

diff --git a/drivers/ufs/core/ufshcd-crypto.c b/drivers/ufs/core/ufshcd-crypto.c
index 399b55d67b3b..c14800eac1ff 100644
--- a/drivers/ufs/core/ufshcd-crypto.c
+++ b/drivers/ufs/core/ufshcd-crypto.c
@@ -119,6 +119,20 @@ static int ufshcd_crypto_keyslot_evict(struct blk_crypto_profile *profile,
 	return ufshcd_clear_keyslot(hba, slot);
 }
 
+static int ufshcd_crypto_derive_sw_secret(struct blk_crypto_profile *profile,
+					  const u8 wkey[], size_t wkey_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_sw_secret)
+		return  hba->vops->derive_sw_secret(hba, wkey, wkey_size,
+						    sw_secret);
+
+	return -EOPNOTSUPP;
+}
+
 bool ufshcd_crypto_enable(struct ufs_hba *hba)
 {
 	if (!(hba->caps & UFSHCD_CAP_CRYPTO))
@@ -132,6 +146,7 @@ bool ufshcd_crypto_enable(struct ufs_hba *hba)
 static const struct blk_crypto_ll_ops ufshcd_crypto_ops = {
 	.keyslot_program	= ufshcd_crypto_keyslot_program,
 	.keyslot_evict		= ufshcd_crypto_keyslot_evict,
+	.derive_sw_secret	= ufshcd_crypto_derive_sw_secret,
 };
 
 static enum blk_crypto_mode_num
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 927db0091722..74865325d141 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -322,6 +322,7 @@ struct ufs_pwr_mode_info {
  * @device_reset: called to issue a reset pulse on the UFS device
  * @config_scaling_param: called to configure clock scaling parameters
  * @program_key: program or evict an inline encryption key
+ * @derive_sw_secret: derive sw secret from a wrapped key
  * @event_notify: called to notify important events
  * @reinit_notify: called to notify reinit of UFSHCD during max gear switch
  * @mcq_config_resource: called to configure MCQ platform resources
@@ -368,6 +369,9 @@ struct ufs_hba_variant_ops {
 	int	(*program_key)(struct ufs_hba *hba,
 			       const struct blk_crypto_key *bkey,
 			       const union ufs_crypto_cfg_entry *cfg, int slot);
+	int	(*derive_sw_secret)(struct ufs_hba *hba, const u8 wkey[],
+				    unsigned int wkey_size,
+				    u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]);
 	void	(*event_notify)(struct ufs_hba *hba,
 				enum ufs_event_type evt, void *data);
 	void	(*reinit_notify)(struct ufs_hba *);
-- 
2.43.0

[PATCH v5 09/15] ufs: core: add support for generate, import and prepare keys

[Gaurav Kashyap]

Block crypto allows storage controllers like UFS to
register ops to generate, prepare and import wrapped
keys in the kernel.

Wrapped keys in most cases will have vendor specific
implementations, which means these ops would need to have
corresponding UFS variant ops.
This change adds hooks in UFS core to support these variant
ops and tie them to the blk crypto ops.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/ufs/core/ufshcd-crypto.c | 41 ++++++++++++++++++++++++++++++++
 include/ufs/ufshcd.h             | 11 +++++++++
 2 files changed, 52 insertions(+)

diff --git a/drivers/ufs/core/ufshcd-crypto.c b/drivers/ufs/core/ufshcd-crypto.c
index c14800eac1ff..fb935a54acfa 100644
--- a/drivers/ufs/core/ufshcd-crypto.c
+++ b/drivers/ufs/core/ufshcd-crypto.c
@@ -143,10 +143,51 @@ bool ufshcd_crypto_enable(struct ufs_hba *hba)
 	return true;
 }
 
+static int ufshcd_crypto_generate_key(struct blk_crypto_profile *profile,
+				      u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct ufs_hba *hba =
+		container_of(profile, struct ufs_hba, crypto_profile);
+
+	if (hba->vops && hba->vops->generate_key)
+		return  hba->vops->generate_key(hba, lt_key);
+
+	return -EOPNOTSUPP;
+}
+
+static int ufshcd_crypto_prepare_key(struct blk_crypto_profile *profile,
+				     const u8 *lt_key, size_t lt_key_size,
+				     u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct ufs_hba *hba =
+		container_of(profile, struct ufs_hba, crypto_profile);
+
+	if (hba->vops && hba->vops->prepare_key)
+		return  hba->vops->prepare_key(hba, lt_key, lt_key_size, eph_key);
+
+	return -EOPNOTSUPP;
+}
+
+static int ufshcd_crypto_import_key(struct blk_crypto_profile *profile,
+				    const u8 *imp_key, size_t imp_key_size,
+				    u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct ufs_hba *hba =
+		container_of(profile, struct ufs_hba, crypto_profile);
+
+	if (hba->vops && hba->vops->import_key)
+		return  hba->vops->import_key(hba, imp_key, imp_key_size, lt_key);
+
+	return -EOPNOTSUPP;
+}
+
 static const struct blk_crypto_ll_ops ufshcd_crypto_ops = {
 	.keyslot_program	= ufshcd_crypto_keyslot_program,
 	.keyslot_evict		= ufshcd_crypto_keyslot_evict,
 	.derive_sw_secret	= ufshcd_crypto_derive_sw_secret,
+	.generate_key		= ufshcd_crypto_generate_key,
+	.prepare_key		= ufshcd_crypto_prepare_key,
+	.import_key		= ufshcd_crypto_import_key,
 };
 
 static enum blk_crypto_mode_num
diff --git a/include/ufs/ufshcd.h b/include/ufs/ufshcd.h
index 74865325d141..4f682f619d66 100644
--- a/include/ufs/ufshcd.h
+++ b/include/ufs/ufshcd.h
@@ -323,6 +323,9 @@ struct ufs_pwr_mode_info {
  * @config_scaling_param: called to configure clock scaling parameters
  * @program_key: program or evict an inline encryption key
  * @derive_sw_secret: derive sw secret from a wrapped key
+ * @generate_key: generate a storage key and return longterm wrapped key
+ * @prepare_key: unwrap longterm key and return ephemeral wrapped key
+ * @import_key: import sw storage key and return longterm wrapped key
  * @event_notify: called to notify important events
  * @reinit_notify: called to notify reinit of UFSHCD during max gear switch
  * @mcq_config_resource: called to configure MCQ platform resources
@@ -372,6 +375,14 @@ struct ufs_hba_variant_ops {
 	int	(*derive_sw_secret)(struct ufs_hba *hba, const u8 wkey[],
 				    unsigned int wkey_size,
 				    u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]);
+	int	(*generate_key)(struct ufs_hba *hba,
+				u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
+	int	(*prepare_key)(struct ufs_hba *hba,
+			       const u8 *lt_key, size_t lt_key_size,
+			       u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
+	int	(*import_key)(struct ufs_hba *hba,
+			      const u8 *imp_key, size_t imp_key_size,
+			      u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
 	void	(*event_notify)(struct ufs_hba *hba,
 				enum ufs_event_type evt, void *data);
 	void	(*reinit_notify)(struct ufs_hba *);
-- 
2.43.0

[PATCH v5 10/15] ufs: host: wrapped keys support in ufs qcom

[Gaurav Kashyap]

Use the wrapped keys quirk when hwkm is supported/used.
Whether to use HWKM or not would be decided during an ICE
probe, and based on this information, UFS can decide to use
wrapped keys or standard keys.

Also, propagate the appropriate key size to the ICE driver
when wrapped keys are used.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/ufs/host/ufs-qcom.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 82584bb318fb..16f846f4a0c3 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -129,6 +129,8 @@ static int ufs_qcom_ice_init(struct ufs_qcom_host *host)
 
 	host->ice = ice;
 	hba->caps |= UFSHCD_CAP_CRYPTO;
+	if (qcom_ice_hwkm_supported(host->ice))
+		hba->quirks |= UFSHCD_QUIRK_USES_WRAPPED_CRYPTO_KEYS;
 
 	return 0;
 }
@@ -166,7 +168,11 @@ static int ufs_qcom_ice_program_key(struct ufs_hba *hba,
 	    cap.key_size != UFS_CRYPTO_KEY_SIZE_256)
 		return -EOPNOTSUPP;
 
-	ice_key_size = QCOM_ICE_CRYPTO_KEY_SIZE_256;
+	if (bkey->crypto_cfg.key_type == BLK_CRYPTO_KEY_TYPE_HW_WRAPPED)
+		ice_key_size = QCOM_ICE_CRYPTO_KEY_SIZE_WRAPPED;
+	else
+		ice_key_size = QCOM_ICE_CRYPTO_KEY_SIZE_256;
+
 	if (config_enable)
 		return qcom_ice_program_key(host->ice,
 					    QCOM_ICE_CRYPTO_ALG_AES_XTS,
-- 
2.43.0

[PATCH v5 11/15] ufs: host: implement derive sw secret vop in ufs qcom

[Gaurav Kashyap]

UFS core defines a variant op to tie the corresponding
derive software secret blk crypto op to the vendor specific
implementation of wrapped keys. This patch implements
this variant op.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/ufs/host/ufs-qcom.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 16f846f4a0c3..d6ac9c147303 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);
+}
+
 #else
 
 #define ufs_qcom_ice_program_key NULL
+#define ufs_qcom_ice_derive_sw_secret NULL
 
 static inline void ufs_qcom_ice_enable(struct ufs_qcom_host *host)
 {
@@ -1810,6 +1824,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
 	.device_reset		= ufs_qcom_device_reset,
 	.config_scaling_param = ufs_qcom_config_scaling_param,
 	.program_key		= ufs_qcom_ice_program_key,
+	.derive_sw_secret	= ufs_qcom_ice_derive_sw_secret,
 	.reinit_notify		= ufs_qcom_reinit_notify,
 	.mcq_config_resource	= ufs_qcom_mcq_config_resource,
 	.get_hba_mac		= ufs_qcom_get_hba_mac,
-- 
2.43.0

[PATCH v5 12/15] ufs: host: support for generate, import and prepare key

[Gaurav Kashyap]

UFS core defines a variant ops to tie the corresponding
generate, prepare and import wrapped key blk crypto ops
to the vendor specific implementation of wrapped keys.
This patch implements these variant ops.

Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 drivers/ufs/host/ufs-qcom.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index d6ac9c147303..971598d099ba 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -195,10 +195,41 @@ static int ufs_qcom_ice_derive_sw_secret(struct ufs_hba *hba, const u8 wkey[],
 	return qcom_ice_derive_sw_secret(host->ice, wkey, wkey_size, sw_secret);
 }
 
+static int ufs_qcom_ice_generate_key(struct ufs_hba *hba,
+				     u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
+
+	return qcom_ice_generate_key(host->ice, lt_key);
+}
+
+static int ufs_qcom_ice_prepare_key(struct ufs_hba *hba,
+				    const u8 *lt_key, size_t lt_key_size,
+				    u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
+
+	return qcom_ice_prepare_key(host->ice, lt_key, lt_key_size,
+				    eph_key);
+}
+
+static int ufs_qcom_ice_import_key(struct ufs_hba *hba,
+				   const u8 *imp_key, size_t imp_key_size,
+				   u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
+{
+	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
+
+	return qcom_ice_import_key(host->ice, imp_key, imp_key_size,
+				   lt_key);
+}
+
 #else
 
 #define ufs_qcom_ice_program_key NULL
 #define ufs_qcom_ice_derive_sw_secret NULL
+#define ufs_qcom_ice_generate_key NULL
+#define ufs_qcom_ice_prepare_key NULL
+#define ufs_qcom_ice_import_key NULL
 
 static inline void ufs_qcom_ice_enable(struct ufs_qcom_host *host)
 {
@@ -1825,6 +1856,9 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
 	.config_scaling_param = ufs_qcom_config_scaling_param,
 	.program_key		= ufs_qcom_ice_program_key,
 	.derive_sw_secret	= ufs_qcom_ice_derive_sw_secret,
+	.generate_key		= ufs_qcom_ice_generate_key,
+	.prepare_key		= ufs_qcom_ice_prepare_key,
+	.import_key		= ufs_qcom_ice_import_key,
 	.reinit_notify		= ufs_qcom_reinit_notify,
 	.mcq_config_resource	= ufs_qcom_mcq_config_resource,
 	.get_hba_mac		= ufs_qcom_get_hba_mac,
-- 
2.43.0

[PATCH v5 13/15] dt-bindings: crypto: ice: document the hwkm property

[Gaurav Kashyap]

When Qualcomm's Inline Crypto Engine (ICE) contains Hardware
Key Manager (HWKM), and the 'HWKM' mode is enabled, it
supports wrapped keys. However, this also requires firmware
support in Trustzone to work correctly, which may not be available
on all chipsets. In the above scenario, ICE needs to support standard
keys even though HWKM is integrated from a hardware perspective.

Introducing this property so that Hardware wrapped key support
can be enabled/disabled from software based on chipset firmware,
and not just based on hardware version.

Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 .../bindings/crypto/qcom,inline-crypto-engine.yaml     | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
index 0304f074cf08..0bb4d008f961 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
@@ -27,6 +27,16 @@ properties:
   clocks:
     maxItems: 1
 
+  qcom,ice-use-hwkm:
+    type: boolean
+    description:
+      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
+      to support wrapped keys. Having this entry helps scenarios where
+      the ICE hardware supports HWKM, but the Trustzone firmware does
+      not have the full capability to use this HWKM and support wrapped
+      keys. Not having this entry enabled would make ICE function in
+      non-HWKM mode supporting standard keys.
+
 required:
   - compatible
   - reg
-- 
2.43.0

[PATCH v5 14/15] arm64: dts: qcom: sm8650: add hwkm support to ufs ice

[Gaurav Kashyap]

The Inline Crypto Engine (ICE) for UFS/EMMC supports the
Hardware Key Manager (HWKM) to securely manage storage
keys. Enable using this hardware on sm8650.

This requires two changes:
1. Register size increase: HWKM is an additional piece of hardware
   sitting alongside ICE, and extends the old ICE's register space.
2. Explicitly tell the ICE driver to use HWKM with ICE so that
   wrapped keys are used in sm8650.

Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sm8650.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
index bb0b3c48ee4b..a34c4b7ccbac 100644
--- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
@@ -2593,9 +2593,11 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
 		ice: crypto@1d88000 {
 			compatible = "qcom,sm8650-inline-crypto-engine",
 				     "qcom,inline-crypto-engine";
-			reg = <0 0x01d88000 0 0x8000>;
+			reg = <0 0x01d88000 0 0x10000>;
 
 			clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+
+			qcom,ice-use-hwkm;
 		};
 
 		tcsr_mutex: hwlock@1f40000 {
-- 
2.43.0

[PATCH v5 15/15] arm64: dts: qcom: sm8550: add hwkm support to ufs ice

[Gaurav Kashyap]

The Inline Crypto Engine (ICE) for UFS/EMMC supports the
Hardware Key Manager (HWKM) to securely manage storage
keys. Enable using this hardware on sm8550.

This requires two changes:
1. Register size increase: HWKM is an additional piece of hardware
   sitting alongside ICE, and extends the old ICE's register space.
2. Explicitly tell the ICE driver to use HWKM with ICE so that
   wrapped keys are used in sm8550.

NOTE: Although wrapped keys cannot be independently generated and
tested on this platform using generate, prepare and import key calls,
there are non-kernel paths to create wrapped keys, and still use the
kernel to program them into ICE. Hence, enabling wrapped key support
on sm8550 too.

Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index c55a818af935..a81f7d54d592 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2076,8 +2076,11 @@ opp-300000000 {
 		ice: crypto@1d88000 {
 			compatible = "qcom,sm8550-inline-crypto-engine",
 				     "qcom,inline-crypto-engine";
-			reg = <0 0x01d88000 0 0x8000>;
+			reg = <0 0x01d88000 0 0x10000>;
+
 			clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
+
+			qcom,ice-use-hwkm;
 		};
 
 		tcsr_mutex: hwlock@1f40000 {
-- 
2.43.0

Re: [PATCH v5 13/15] dt-bindings: crypto: ice: document the hwkm property

[Krzysztof Kozlowski]

On 17/06/2024 02:51, Gaurav Kashyap wrote:
> +  qcom,ice-use-hwkm:
> +    type: boolean
> +    description:
> +      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
> +      to support wrapped keys. Having this entry helps scenarios where
> +      the ICE hardware supports HWKM, but the Trustzone firmware does
> +      not have the full capability to use this HWKM and support wrapped
> +      keys. Not having this entry enabled would make ICE function in
> +      non-HWKM mode supporting standard keys.

No changelog, previous comments and discussion ignored.

NAK

Best regards,
Krzysztof

Re: [PATCH v5 00/15] Hardware wrapped key support for qcom ice and ufs

[Krzysztof Kozlowski]

On 17/06/2024 02:50, Gaurav Kashyap wrote:
> The fifth iteration of patches that add support to Qualcomm ICE (Inline Crypto Engine) for hardware wrapped keys using Qualcomm Hardware Key Manager (HWKM)
> 
> They patches do the following:
> - Address comments from previous versions (https://lore.kernel.org/all/20240127232436.2632187-1-quic_gaurkash@quicinc.com/)

First, that's not true. Second, that's way to vague.

Best regards,
Krzysztof

Re: [PATCH v5 02/15] qcom_scm: scm call for deriving a software secret

[Dmitry Baryshkov]

On Sun, Jun 16, 2024 at 05:50:57PM GMT, Gaurav Kashyap wrote:
> Inline storage encryption may require deriving a software
> secret from storage keys added to the kernel.
> 
> For non-wrapped keys, this can be directly done in the kernel as
> keys are in the clear.
> 
> However, hardware wrapped keys can only be unwrapped by the wrapping
> entity. In case of Qualcomm's wrapped key solution, this is done by
> the Hardware Key Manager (HWKM) from Trustzone.
> Hence, adding a new SCM call which in the end provides a hook
> to the software secret crypto profile API provided by the block
> layer.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c       | 65 ++++++++++++++++++++++++++
>  drivers/firmware/qcom/qcom_scm.h       |  1 +
>  include/linux/firmware/qcom/qcom_scm.h |  2 +
>  3 files changed, 68 insertions(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

-- 
With best wishes
Dmitry

Re: [PATCH v5 03/15] qcom_scm: scm call for create, prepare and import keys

[Dmitry Baryshkov]

On Sun, Jun 16, 2024 at 05:50:58PM GMT, 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.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c       | 175 +++++++++++++++++++++++++
>  drivers/firmware/qcom/qcom_scm.h       |   3 +
>  include/linux/firmware/qcom/qcom_scm.h |   5 +
>  3 files changed, 183 insertions(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 8f23b459c525..61a1ace3c683 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -1309,6 +1309,181 @@ 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..

This is documentation to a function, not a changelog. Also the function
helps implementing the IOCTL. Please describe the call itself and its
behaviour. Something like:

Generate a key using built-in entropy source (or using this-and-that
PRNG) inside TZ. Wrap the key using the platform-specific
(board-specific?) Key Encryption Key and return to the caller.

The same comment applies to other SCM calls added in this patch.

-- 
With best wishes
Dmitry

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Sun, Jun 16, 2024 at 05:50:59PM GMT, Gaurav Kashyap wrote:
> Qualcomm's ICE (Inline Crypto Engine) contains a proprietary
> key management hardware called Hardware Key Manager (HWKM).
> This patch integrates HWKM support in ICE when it is
> available. HWKM primarily provides hardware wrapped key support
> where the ICE (storage) keys are not available in software and
> 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, standard keys have
> to be used without using HWKM. Hence, providing a toggle controlled
> by a devicetree entry to use HWKM or not.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/soc/qcom/ice.c | 153 +++++++++++++++++++++++++++++++++++++++--
>  include/soc/qcom/ice.h |   1 +
>  2 files changed, 150 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index 6f941d32fffb..d5e74cf2946b 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -26,6 +26,40 @@
>  #define QCOM_ICE_REG_FUSE_SETTING		0x0010
>  #define QCOM_ICE_REG_BIST_STATUS		0x0070
>  #define QCOM_ICE_REG_ADVANCED_CONTROL		0x1000
> +#define QCOM_ICE_REG_CONTROL			0x0
> +/* QCOM ICE HWKM registers */
> +#define QCOM_ICE_REG_HWKM_TZ_KM_CTL			0x1000
> +#define QCOM_ICE_REG_HWKM_TZ_KM_STATUS			0x1004
> +#define QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS	0x2008
> +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_0			0x5000
> +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_1			0x5004
> +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_2			0x5008
> +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_3			0x500C
> +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_4			0x5010
> +
> +/* QCOM ICE HWKM reg vals */
> +#define QCOM_ICE_HWKM_BIST_DONE_V1		BIT(16)
> +#define QCOM_ICE_HWKM_BIST_DONE_V2		BIT(9)
> +#define QCOM_ICE_HWKM_BIST_DONE(ver)		QCOM_ICE_HWKM_BIST_DONE_V##ver
> +
> +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V1		BIT(14)
> +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V2		BIT(7)
> +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v)		QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V##v
> +
> +#define QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE		BIT(2)
> +#define QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE		BIT(1)
> +#define QCOM_ICE_HWKM_KT_CLEAR_DONE			BIT(0)
> +
> +#define QCOM_ICE_HWKM_BIST_VAL(v)	(QCOM_ICE_HWKM_BIST_DONE(v) |		\
> +					QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v) |	\
> +					QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE |	\
> +					QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE |	\
> +					QCOM_ICE_HWKM_KT_CLEAR_DONE)
> +
> +#define QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL	(BIT(0) | BIT(1) | BIT(2))
> +#define QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK	GENMASK(31, 1)
> +#define QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL	(BIT(1) | BIT(2))
> +#define QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL	BIT(3)
>  
>  /* BIST ("built-in self-test") status flags */
>  #define QCOM_ICE_BIST_STATUS_MASK		GENMASK(31, 28)
> @@ -34,6 +68,9 @@
>  #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK	0x2
>  #define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK	0x4
>  
> +#define QCOM_ICE_HWKM_REG_OFFSET	0x8000
> +#define HWKM_OFFSET(reg)		((reg) + QCOM_ICE_HWKM_REG_OFFSET)
> +
>  #define qcom_ice_writel(engine, val, reg)	\
>  	writel((val), (engine)->base + (reg))
>  
> @@ -46,6 +83,9 @@ struct qcom_ice {
>  	struct device_link *link;
>  
>  	struct clk *core_clk;
> +	u8 hwkm_version;
> +	bool use_hwkm;
> +	bool hwkm_init_complete;
>  };
>  
>  static bool qcom_ice_check_supported(struct qcom_ice *ice)
> @@ -63,8 +103,21 @@ static bool qcom_ice_check_supported(struct qcom_ice *ice)
>  		return false;
>  	}
>  
> -	dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
> -		 major, minor, step);
> +	if (major >= 4 || (major == 3 && minor == 2 && step >= 1))
> +		ice->hwkm_version = 2;
> +	else if (major == 3 && minor == 2)
> +		ice->hwkm_version = 1;
> +	else
> +		ice->hwkm_version = 0;
> +
> +	if (ice->hwkm_version == 0)
> +		ice->use_hwkm = false;
> +
> +	dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d, HWKM v%d\n",
> +		 major, minor, step, ice->hwkm_version);
> +
> +	if (!ice->use_hwkm)
> +		dev_info(dev, "QC ICE HWKM (Hardware Key Manager) not used/supported");
>  
>  	/* If fuses are blown, ICE might not work in the standard way. */
>  	regval = qcom_ice_readl(ice, QCOM_ICE_REG_FUSE_SETTING);
> @@ -113,27 +166,106 @@ static void qcom_ice_optimization_enable(struct qcom_ice *ice)
>   * fails, so we needn't do it in software too, and (c) properly testing
>   * storage encryption requires testing the full storage stack anyway,
>   * and not relying on hardware-level self-tests.
> + *
> + * However, we still care about if HWKM BIST failed (when supported) as
> + * important functionality would fail later, so disable hwkm on failure.
>   */
>  static int qcom_ice_wait_bist_status(struct qcom_ice *ice)
>  {
>  	u32 regval;
> +	u32 bist_done_val;
>  	int err;
>  
>  	err = readl_poll_timeout(ice->base + QCOM_ICE_REG_BIST_STATUS,
>  				 regval, !(regval & QCOM_ICE_BIST_STATUS_MASK),
>  				 50, 5000);
> -	if (err)
> +	if (err) {
>  		dev_err(ice->dev, "Timed out waiting for ICE self-test to complete\n");
> +		return err;
> +	}
>  
> +	if (ice->use_hwkm) {
> +		bist_done_val = ice->hwkm_version == 1 ?
> +				QCOM_ICE_HWKM_BIST_VAL(1) :
> +				QCOM_ICE_HWKM_BIST_VAL(2);
> +		if (qcom_ice_readl(ice,
> +				   HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_STATUS)) !=
> +				   bist_done_val) {
> +			dev_err(ice->dev, "HWKM BIST error\n");
> +			ice->use_hwkm = false;
> +			err = -ENODEV;
> +		}
> +	}
>  	return err;
>  }
>  
> +static void qcom_ice_enable_standard_mode(struct qcom_ice *ice)
> +{
> +	u32 val = 0;
> +
> +	/*
> +	 * When ICE is in standard (hwkm) mode, it supports HW wrapped
> +	 * keys, and when it is in legacy mode, it only supports standard
> +	 * (non HW wrapped) keys.

I can't say this is very logical.

standard mode => HW wrapped keys
legacy mode => standard keys

Consider changing the terms.

> +	 *
> +	 * Put ICE in standard mode, ICE defaults to legacy mode.
> +	 * Legacy mode - ICE HWKM slave not supported.
> +	 * Standard mode - ICE HWKM slave supported.

s/slave/some other term/

Is it possible to use both kind of keys when working on standard mode?
If not, it should be the user who selects what type of keys to be used.
Enforcing this via DT is not a way to go.

> +	 *
> +	 * Depending on the version of HWKM, it is controlled by different
> +	 * registers in ICE.
> +	 */
> +	if (ice->hwkm_version >= 2) {
> +		val = qcom_ice_readl(ice, QCOM_ICE_REG_CONTROL);
> +		val = val & QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK;
> +		qcom_ice_writel(ice, val, QCOM_ICE_REG_CONTROL);
> +	} else {
> +		qcom_ice_writel(ice, QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL,
> +				HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_CTL));
> +	}
> +}
> +
> +static void qcom_ice_hwkm_init(struct qcom_ice *ice)
> +{
> +	/* Disable CRC checks. This HWKM feature is not used. */
> +	qcom_ice_writel(ice, QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL,
> +			HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_CTL));
> +
> +	/*
> +	 * Give register bank of the HWKM slave access to read and modify
> +	 * the keyslots in ICE HWKM slave. Without this, trustzone will not
> +	 * be able to program keys into ICE.
> +	 */
> +	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_0));
> +	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_1));
> +	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_2));
> +	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_3));
> +	qcom_ice_writel(ice, GENMASK(31, 0), HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_4));
> +
> +	/* Clear HWKM response FIFO before doing anything */
> +	qcom_ice_writel(ice, QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL,
> +			HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS));
> +	ice->hwkm_init_complete = true;
> +}
> +
>  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);
>  
> @@ -149,6 +281,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);
> @@ -156,6 +292,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;
>  }
> @@ -205,6 +342,12 @@ int qcom_ice_evict_key(struct qcom_ice *ice, int slot)
>  }
>  EXPORT_SYMBOL_GPL(qcom_ice_evict_key);
>  

Documentation?

> +bool qcom_ice_hwkm_supported(struct qcom_ice *ice)
> +{
> +	return ice->use_hwkm;

I see that use_hwkm can change during runtime. Will it have an impact on
a driver that calls this first?

> +}
> +EXPORT_SYMBOL_GPL(qcom_ice_hwkm_supported);
> +
>  static struct qcom_ice *qcom_ice_create(struct device *dev,
>  					void __iomem *base)
>  {
> @@ -239,6 +382,8 @@ 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 = of_property_read_bool(dev->of_node,
> +						 "qcom,ice-use-hwkm");

DT bindings should come before driver changes.

>  
>  	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
> 

-- 
With best wishes
Dmitry

Re: [PATCH v5 05/15] soc: qcom: ice: support for hardware wrapped keys

[Dmitry Baryshkov]

On Sun, Jun 16, 2024 at 05:51:00PM GMT, Gaurav Kashyap wrote:
> Now that HWKM support is added to ICE, extend the ICE
> driver to support hardware wrapped keys programming coming
> in from the storage controllers (ufs and emmc). This is
> similar to standard keys where the call is forwarded to

standard keys = ?

> Trustzone, however certain wrapped key and HWKM specific
> actions has to be performed around the SCM calls.

which actions? Be specific here.


> 
> Derive software secret support is also added by forwarding the
> call to the corresponding scm api.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/soc/qcom/ice.c | 119 +++++++++++++++++++++++++++++++++++++----
>  include/soc/qcom/ice.h |   4 ++
>  2 files changed, 112 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index d5e74cf2946b..f0e9e0885732 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -27,6 +27,8 @@
>  #define QCOM_ICE_REG_BIST_STATUS		0x0070
>  #define QCOM_ICE_REG_ADVANCED_CONTROL		0x1000
>  #define QCOM_ICE_REG_CONTROL			0x0
> +#define QCOM_ICE_LUT_KEYS_CRYPTOCFG_R16		0x4040
> +
>  /* QCOM ICE HWKM registers */
>  #define QCOM_ICE_REG_HWKM_TZ_KM_CTL			0x1000
>  #define QCOM_ICE_REG_HWKM_TZ_KM_STATUS			0x1004
> @@ -68,6 +70,8 @@
>  #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK	0x2
>  #define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK	0x4
>  
> +#define QCOM_ICE_LUT_KEYS_CRYPTOCFG_OFFSET	0x80
> +
>  #define QCOM_ICE_HWKM_REG_OFFSET	0x8000
>  #define HWKM_OFFSET(reg)		((reg) + QCOM_ICE_HWKM_REG_OFFSET)
>  
> @@ -88,6 +92,16 @@ struct qcom_ice {
>  	bool hwkm_init_complete;
>  };
>  
> +union crypto_cfg {
> +	__le32 regval;
> +	struct {
> +		u8 dusize;
> +		u8 capidx;
> +		u8 reserved;
> +		u8 cfge;
> +	};
> +};
> +
>  static bool qcom_ice_check_supported(struct qcom_ice *ice)
>  {
>  	u32 regval = qcom_ice_readl(ice, QCOM_ICE_REG_VERSION);
> @@ -298,6 +312,51 @@ int qcom_ice_suspend(struct qcom_ice *ice)
>  }
>  EXPORT_SYMBOL_GPL(qcom_ice_suspend);
>  
> +/*
> + * HW dictates the internal mapping between the ICE and HWKM slots,
> + * which are different for different versions, make the translation
> + * here. For v1 however, the translation is done in trustzone.

THis doesn't really help.

> + */
> +static int translate_hwkm_slot(struct qcom_ice *ice, int slot)
> +{
> +	return (ice->hwkm_version == 1) ? slot : (slot * 2);
> +}
> +
> +static int qcom_ice_program_wrapped_key(struct qcom_ice *ice,
> +					const struct blk_crypto_key *key,
> +					u8 data_unit_size, int slot)
> +{
> +	union crypto_cfg cfg;
> +	int hwkm_slot;
> +	int err;
> +
> +	hwkm_slot = translate_hwkm_slot(ice, slot);
> +
> +	memset(&cfg, 0, sizeof(cfg));
> +	cfg.dusize = data_unit_size;
> +	cfg.capidx = QCOM_SCM_ICE_CIPHER_AES_256_XTS;
> +	cfg.cfge = 0x80;
> +
> +	/* Clear CFGE */
> +	qcom_ice_writel(ice, 0x0, QCOM_ICE_LUT_KEYS_CRYPTOCFG_R16 +
> +				  QCOM_ICE_LUT_KEYS_CRYPTOCFG_OFFSET * slot);

#define register address instead.

> +
> +	/* Call trustzone to program the wrapped key using hwkm */
> +	err = qcom_scm_ice_set_key(hwkm_slot, key->raw, key->size,
> +				   QCOM_SCM_ICE_CIPHER_AES_256_XTS, data_unit_size);
> +	if (err) {
> +		pr_err("%s:SCM call Error: 0x%x slot %d\n", __func__, err,
> +		       slot);
> +		return err;
> +	}
> +
> +	/* Enable CFGE after programming key */
> +	qcom_ice_writel(ice, cfg.regval, QCOM_ICE_LUT_KEYS_CRYPTOCFG_R16 +
> +					 QCOM_ICE_LUT_KEYS_CRYPTOCFG_OFFSET * slot);
> +
> +	return err;
> +}
> +
>  int qcom_ice_program_key(struct qcom_ice *ice,
>  			 u8 algorithm_id, u8 key_size,
>  			 const struct blk_crypto_key *bkey,


-- 
With best wishes
Dmitry

Re: [PATCH v5 06/15] soc: qcom: ice: support for generate, import and prepare key

[Dmitry Baryshkov]

On Sun, Jun 16, 2024 at 05:51:01PM GMT, Gaurav Kashyap wrote:
> Wrapped key creation and management using HWKM is currently
> supported only through Qualcomm's Trustzone.
> Three new SCM calls have already been added in the scm layer
> for this purpose.
> 
> This patch adds support for generate, prepare and import key
> apis in ICE module and hooks it up the scm calls defined for them.
> This will eventually plug into the new IOCTLS added for this
> usecase in the block layer.

Documentation/process/submitting-patches.rst. "This patch..."

> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/soc/qcom/ice.c | 75 ++++++++++++++++++++++++++++++++++++++++++
>  include/soc/qcom/ice.h |  8 +++++
>  2 files changed, 83 insertions(+)
> 
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index f0e9e0885732..68062b27f40c 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -21,6 +21,13 @@
>  
>  #define AES_256_XTS_KEY_SIZE			64
>  
> +/*
> + * Wrapped key sizes that HWKM expects and manages is different for different
> + * versions of the hardware.
> + */
> +#define QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(v)	\
> +	((v) == 1 ? 68 : 100)
> +
>  /* QCOM ICE registers */
>  #define QCOM_ICE_REG_VERSION			0x0008
>  #define QCOM_ICE_REG_FUSE_SETTING		0x0010
> @@ -445,6 +452,74 @@ int qcom_ice_derive_sw_secret(struct qcom_ice *ice, const u8 wkey[],
>  }
>  EXPORT_SYMBOL_GPL(qcom_ice_derive_sw_secret);
>  
> +/**
> + * qcom_ice_generate_key() - Generate a wrapped key for inline encryption
> + * @lt_key: longterm wrapped key that is generated, which is
> + *          BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE in size.
> + *
> + * Make a scm call into trustzone to generate a wrapped key for storage
> + * encryption using hwkm.
> + *
> + * Return: lt wrapped key size on success; err on failure.

This is incorrect.

> + */
> +int qcom_ice_generate_key(struct qcom_ice *ice,
> +			  u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
> +{
> +	size_t wk_size = QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(ice->hwkm_version);
> +
> +	if (!qcom_scm_generate_ice_key(lt_key, wk_size))
> +		return wk_size;
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_ice_generate_key);
> +
> +/**
> + * qcom_ice_prepare_key() - Prepare a longterm wrapped key for inline encryption
> + * @lt_key: longterm wrapped key that is generated or imported.
> + * @lt_key_size: size of the longterm wrapped_key
> + * @eph_key: wrapped key returned which has been wrapped with a per-boot ephemeral key,
> + *           size of which is BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE in size.
> + *
> + * Make a scm call into trustzone to prepare a wrapped key for storage
> + * encryption by rewrapping the longterm wrapped key with a per boot ephemeral
> + * key using hwkm.
> + *
> + * Return: eph wrapped key size on success; err on failure.

And this too.

> + */
> +int qcom_ice_prepare_key(struct qcom_ice *ice, const u8 *lt_key, size_t lt_key_size,
> +			 u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
> +{
> +	size_t wk_size = QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(ice->hwkm_version);
> +
> +	if (!qcom_scm_prepare_ice_key(lt_key, lt_key_size, eph_key, wk_size))
> +		return wk_size;
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_ice_prepare_key);
> +
> +/**
> + * qcom_ice_import_key() - Import a raw key for inline encryption
> + * @imp_key: raw key that has to be imported
> + * @imp_key_size: size of the imported key
> + * @lt_key: longterm wrapped key that is imported, which is
> + *          BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE in size.
> + *
> + * Make a scm call into trustzone to import a raw key for storage encryption
> + * and generate a longterm wrapped key using hwkm.
> + *
> + * Return: lt wrapped key size on success; err on failure.

Guess, this is incorrect too.

> + */
> +int qcom_ice_import_key(struct qcom_ice *ice, const u8 *imp_key, size_t imp_key_size,
> +			u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
> +{
> +	size_t wk_size = QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(ice->hwkm_version);
> +
> +	if (!qcom_scm_import_ice_key(imp_key, imp_key_size, lt_key, wk_size))
> +		return wk_size;
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(qcom_ice_import_key);
> +
>  static struct qcom_ice *qcom_ice_create(struct device *dev,
>  					void __iomem *base)
>  {
> diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
> index dabe0d3a1fd0..dcf277d196ff 100644
> --- a/include/soc/qcom/ice.h
> +++ b/include/soc/qcom/ice.h
> @@ -39,5 +39,13 @@ bool qcom_ice_hwkm_supported(struct qcom_ice *ice);
>  int qcom_ice_derive_sw_secret(struct qcom_ice *ice, const u8 wkey[],
>  			      unsigned int wkey_size,
>  			      u8 sw_secret[BLK_CRYPTO_SW_SECRET_SIZE]);
> +int qcom_ice_generate_key(struct qcom_ice *ice,
> +			  u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
> +int qcom_ice_prepare_key(struct qcom_ice *ice,
> +			 const u8 *lt_key, size_t lt_key_size,
> +			 u8 eph_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
> +int qcom_ice_import_key(struct qcom_ice *ice,
> +			const u8 *imp_key, size_t imp_key_size,
> +			u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
>  struct qcom_ice *of_qcom_ice_get(struct device *dev);
>  #endif /* __QCOM_ICE_H__ */
> -- 
> 2.43.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v5 07/15] ufs: core: support wrapped keys in ufs core

[Dmitry Baryshkov]

On Sun, Jun 16, 2024 at 05:51:02PM GMT, Gaurav Kashyap wrote:
> Since wrapped keys are not part of the UFS specifications,
> it needs to be treated as a supported quirk of the UFS
> controller. This way, based on the quirk set during a host
> probe, UFS crypto can choose to register either standard or
> wrapped keys with block crypto profile.

No. It is the user who must be able to select whether to use HW-wrapped
keys or not. The hardware / driver can only specify whether HW-wrapped
keys are supported or not.

> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  drivers/ufs/core/ufshcd-crypto.c | 24 ++++++++++++++++--------
>  include/ufs/ufshcd.h             |  6 ++++++
>  2 files changed, 22 insertions(+), 8 deletions(-)
> 


-- 
With best wishes
Dmitry

Re: [PATCH v5 14/15] arm64: dts: qcom: sm8650: add hwkm support to ufs ice

[Krzysztof Kozlowski]

On 17/06/2024 02:51, Gaurav Kashyap wrote:
> The Inline Crypto Engine (ICE) for UFS/EMMC supports the
> Hardware Key Manager (HWKM) to securely manage storage
> keys. Enable using this hardware on sm8650.
> 
> This requires two changes:
> 1. Register size increase: HWKM is an additional piece of hardware
>    sitting alongside ICE, and extends the old ICE's register space.
> 2. Explicitly tell the ICE driver to use HWKM with ICE so that
>    wrapped keys are used in sm8650.
> 
> Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>  arch/arm64/boot/dts/qcom/sm8650.dtsi | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index bb0b3c48ee4b..a34c4b7ccbac 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -2593,9 +2593,11 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>  		ice: crypto@1d88000 {
>  			compatible = "qcom,sm8650-inline-crypto-engine",
>  				     "qcom,inline-crypto-engine";
> -			reg = <0 0x01d88000 0 0x8000>;
> +			reg = <0 0x01d88000 0 0x10000>;
>  
>  			clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
> +
> +			qcom,ice-use-hwkm;

Nah... this proves this is compatible specific, so drop the property.

You already ignored such feedback once, so let me be clear: respond that
you acknowledge the comment and that you will implement it.

Best regards,
Krzysztof

Re: [PATCH v5 14/15] arm64: dts: qcom: sm8650: add hwkm support to ufs ice

[neil.armstrong]

Hi,

On 17/06/2024 02:51, Gaurav Kashyap wrote:
> The Inline Crypto Engine (ICE) for UFS/EMMC supports the
> Hardware Key Manager (HWKM) to securely manage storage
> keys. Enable using this hardware on sm8650.
> 
> This requires two changes:
> 1. Register size increase: HWKM is an additional piece of hardware
>     sitting alongside ICE, and extends the old ICE's register space.
> 2. Explicitly tell the ICE driver to use HWKM with ICE so that
>     wrapped keys are used in sm8650.
> 
> Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>   arch/arm64/boot/dts/qcom/sm8650.dtsi | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index bb0b3c48ee4b..a34c4b7ccbac 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> @@ -2593,9 +2593,11 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>   		ice: crypto@1d88000 {
>   			compatible = "qcom,sm8650-inline-crypto-engine",
>   				     "qcom,inline-crypto-engine";
> -			reg = <0 0x01d88000 0 0x8000>;
> +			reg = <0 0x01d88000 0 0x10000>;
>   
>   			clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
> +
> +			qcom,ice-use-hwkm;
>   		};
>   
>   		tcsr_mutex: hwlock@1f40000 {

Please split this (and next) in two patches:
- one extending the register size + Fixes tag so it can backported to stable kernels
- one adding qcom,ice-use-hwkm (if bindings maintainers agrees with this property)

And please send sm8550 before sm8650...

Thanks,
Neil

Re: [PATCH v5 08/15] ufs: core: add support to derive software secret

[Konrad Dybcio]

On 6/17/24 02:51, Gaurav Kashyap wrote:
> Block crypto allows storage controllers like UFS to
> register an op derive a software secret from wrapped
> keys added to the kernel.
> 
> Wrapped keys in most cases will have vendor specific
> implementations, which means this op would need to have
> a corresponding UFS variant op.
> This change adds hooks in UFS core to support this variant
> ops and tie them to the blk crypto op.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>   drivers/ufs/core/ufshcd-crypto.c | 15 +++++++++++++++
>   include/ufs/ufshcd.h             |  4 ++++
>   2 files changed, 19 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufshcd-crypto.c b/drivers/ufs/core/ufshcd-crypto.c
> index 399b55d67b3b..c14800eac1ff 100644
> --- a/drivers/ufs/core/ufshcd-crypto.c
> +++ b/drivers/ufs/core/ufshcd-crypto.c
> @@ -119,6 +119,20 @@ static int ufshcd_crypto_keyslot_evict(struct blk_crypto_profile *profile,
>   	return ufshcd_clear_keyslot(hba, slot);
>   }
>   
> +static int ufshcd_crypto_derive_sw_secret(struct blk_crypto_profile *profile,
> +					  const u8 wkey[], size_t wkey_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_sw_secret)
> +		return  hba->vops->derive_sw_secret(hba, wkey, wkey_size,

Double space

Konrad

Re: [PATCH v5 09/15] ufs: core: add support for generate, import and prepare keys

[Konrad Dybcio]

On 6/17/24 02:51, Gaurav Kashyap wrote:
> Block crypto allows storage controllers like UFS to
> register ops to generate, prepare and import wrapped
> keys in the kernel.
> 
> Wrapped keys in most cases will have vendor specific
> implementations, which means these ops would need to have
> corresponding UFS variant ops.
> This change adds hooks in UFS core to support these variant
> ops and tie them to the blk crypto ops.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>   drivers/ufs/core/ufshcd-crypto.c | 41 ++++++++++++++++++++++++++++++++
>   include/ufs/ufshcd.h             | 11 +++++++++
>   2 files changed, 52 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufshcd-crypto.c b/drivers/ufs/core/ufshcd-crypto.c
> index c14800eac1ff..fb935a54acfa 100644
> --- a/drivers/ufs/core/ufshcd-crypto.c
> +++ b/drivers/ufs/core/ufshcd-crypto.c
> @@ -143,10 +143,51 @@ bool ufshcd_crypto_enable(struct ufs_hba *hba)
>   	return true;
>   }
>   
> +static int ufshcd_crypto_generate_key(struct blk_crypto_profile *profile,
> +				      u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE])
> +{
> +	struct ufs_hba *hba =
> +		container_of(profile, struct ufs_hba, crypto_profile);
> +
> +	if (hba->vops && hba->vops->generate_key)
> +		return  hba->vops->generate_key(hba, lt_key);

Couple more double spaces in this one

Konrad

Re: [PATCH v5 13/15] dt-bindings: crypto: ice: document the hwkm property

[Konrad Dybcio]

On 6/17/24 02:51, Gaurav Kashyap wrote:
> When Qualcomm's Inline Crypto Engine (ICE) contains Hardware
> Key Manager (HWKM), and the 'HWKM' mode is enabled, it
> supports wrapped keys. However, this also requires firmware
> support in Trustzone to work correctly, which may not be available
> on all chipsets. In the above scenario, ICE needs to support standard
> keys even though HWKM is integrated from a hardware perspective.
> 
> Introducing this property so that Hardware wrapped key support
> can be enabled/disabled from software based on chipset firmware,
> and not just based on hardware version.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>   .../bindings/crypto/qcom,inline-crypto-engine.yaml     | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> index 0304f074cf08..0bb4d008f961 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> @@ -27,6 +27,16 @@ properties:
>     clocks:
>       maxItems: 1
>   
> +  qcom,ice-use-hwkm:
> +    type: boolean
> +    description:
> +      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
> +      to support wrapped keys. Having this entry helps scenarios where
> +      the ICE hardware supports HWKM, but the Trustzone firmware does
> +      not have the full capability to use this HWKM and support wrapped
> +      keys. Not having this entry enabled would make ICE function in
> +      non-HWKM mode supporting standard keys.

Just check if qcom_scm_derive_sw_secret is available instead

Konrad

Re: [PATCH v5 14/15] arm64: dts: qcom: sm8650: add hwkm support to ufs ice

[Konrad Dybcio]

On 6/17/24 10:28, neil.armstrong@linaro.org wrote:
> Hi,
> 
> On 17/06/2024 02:51, Gaurav Kashyap wrote:
>> The Inline Crypto Engine (ICE) for UFS/EMMC supports the
>> Hardware Key Manager (HWKM) to securely manage storage
>> keys. Enable using this hardware on sm8650.
>>
>> This requires two changes:
>> 1. Register size increase: HWKM is an additional piece of hardware
>>     sitting alongside ICE, and extends the old ICE's register space.
>> 2. Explicitly tell the ICE driver to use HWKM with ICE so that
>>     wrapped keys are used in sm8650.
>>
>> Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>
>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
>> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
>> ---
>>   arch/arm64/boot/dts/qcom/sm8650.dtsi | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> index bb0b3c48ee4b..a34c4b7ccbac 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
>> @@ -2593,9 +2593,11 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>>           ice: crypto@1d88000 {
>>               compatible = "qcom,sm8650-inline-crypto-engine",
>>                        "qcom,inline-crypto-engine";
>> -            reg = <0 0x01d88000 0 0x8000>;
>> +            reg = <0 0x01d88000 0 0x10000>;
>>               clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
>> +
>> +            qcom,ice-use-hwkm;
>>           };
>>           tcsr_mutex: hwlock@1f40000 {
> 
> Please split this (and next) in two patches:
> - one extending the register size + Fixes tag so it can backported to stable kernels

Would also be helpful to know which chipsets require this, so we can
fix it up. FWIW:

rg qcom,ufshc arch/arm64/boot/dts/qcom -l | wc -l

returns 17

Konrad

RE: [PATCH v5 13/15] dt-bindings: crypto: ice: document the hwkm property

[Gaurav Kashyap (QUIC)]

Hello Krzysztof

On   06/17/2024 12:17 AM PDT, Krzysztof Kozlowski wrote:
> On 17/06/2024 02:51, Gaurav Kashyap wrote:
> > +  qcom,ice-use-hwkm:
> > +    type: boolean
> > +    description:
> > +      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
> > +      to support wrapped keys. Having this entry helps scenarios where
> > +      the ICE hardware supports HWKM, but the Trustzone firmware does
> > +      not have the full capability to use this HWKM and support wrapped
> > +      keys. Not having this entry enabled would make ICE function in
> > +      non-HWKM mode supporting standard keys.
> 
> No changelog, previous comments and discussion ignored.
> 
> NAK

Apologies for not addressing the previous comments.
https://lore.kernel.org/all/9892c541ba4e4b5d975faaa4b49c92ba@quicinc.com/

Maybe we can continue our discussion here;
" SM8450 and SM8350 QCOM ICE both support HWKM in their ICE hardware.
However, wrapped keys can not be enabled on those targets due to certain
missing trustzone support. If we solely rely on hardware version to decide
if ICE has to use wrapped keys for data encryption, then it becomes untestable
on those chipsets. 

So, we want another way to distinguish this scenario, and hence I chose a DT vendor property
to explicitly mention if we have to use the supported HWKM.
If there is another way, I am open to exploring that as well."

> 
> Best regards,
> Krzysztof

Regards, 
Gaurav

Re: [PATCH v5 13/15] dt-bindings: crypto: ice: document the hwkm property

[Krzysztof Kozlowski]

On 18/06/2024 02:35, Gaurav Kashyap (QUIC) wrote:
> Hello Krzysztof
> 
> On   06/17/2024 12:17 AM PDT, Krzysztof Kozlowski wrote:
>> On 17/06/2024 02:51, Gaurav Kashyap wrote:
>>> +  qcom,ice-use-hwkm:
>>> +    type: boolean
>>> +    description:
>>> +      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
>>> +      to support wrapped keys. Having this entry helps scenarios where
>>> +      the ICE hardware supports HWKM, but the Trustzone firmware does
>>> +      not have the full capability to use this HWKM and support wrapped
>>> +      keys. Not having this entry enabled would make ICE function in
>>> +      non-HWKM mode supporting standard keys.
>>
>> No changelog, previous comments and discussion ignored.
>>
>> NAK
> 
> Apologies for not addressing the previous comments.
> https://lore.kernel.org/all/9892c541ba4e4b5d975faaa4b49c92ba@quicinc.com/
> 
> Maybe we can continue our discussion here;
> " SM8450 and SM8350 QCOM ICE both support HWKM in their ICE hardware.
> However, wrapped keys can not be enabled on those targets due to certain
> missing trustzone support. If we solely rely on hardware version to decide
> if ICE has to use wrapped keys for data encryption, then it becomes untestable
> on those chipsets. 

That does not make any sense to me. You enable it for SM8550 and SM8650
not SM8450 and SM8350.

> 
> So, we want another way to distinguish this scenario, and hence I chose a DT vendor property

What scenario? Show it in your patches.

> to explicitly mention if we have to use the supported HWKM.
> If there is another way, I am open to exploring that as well."

That property is just entirely redundant. If you claim otherwise, show
it through patches.

To be clear, so you will not resend the same ignoring comments: NAK.

Best regards,
Krzysztof

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[neil.armstrong]

On 17/06/2024 02:50, Gaurav Kashyap wrote:
> Qualcomm's ICE (Inline Crypto Engine) contains a proprietary
> key management hardware called Hardware Key Manager (HWKM).
> This patch integrates HWKM support in ICE when it is
> available. HWKM primarily provides hardware wrapped key support
> where the ICE (storage) keys are not available in software and
> 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, standard keys have
> to be used without using HWKM. Hence, providing a toggle controlled
> by a devicetree entry to use HWKM or not.
> 
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> ---
>   drivers/soc/qcom/ice.c | 153 +++++++++++++++++++++++++++++++++++++++--
>   include/soc/qcom/ice.h |   1 +
>   2 files changed, 150 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index 6f941d32fffb..d5e74cf2946b 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -26,6 +26,40 @@

<snip>

> +
>   static struct qcom_ice *qcom_ice_create(struct device *dev,
>   					void __iomem *base)
>   {
> @@ -239,6 +382,8 @@ 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 = of_property_read_bool(dev->of_node,
> +						 "qcom,ice-use-hwkm");

Please drop this property and instead add an scm function calling:

__qcom_scm_is_call_available(QCOM_SCM_SVC_ES, QCOM_SCM_ES_DERIVE_SW_SECRET)

like

bool qcom_scm_derive_sw_secret_available(void)
{
	if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
					  QCOM_SCM_ES_DERIVE_SW_SECRET))
		return false;

	return true;
}

You may perhaps only call qcom_scm_derive_sw_secret_available() for some
ICE versions.

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__ */

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap (QUIC)]

Hello Dmitry,

On 06/17/2024 12:55 AM PDT, Dmitry Baryshkov wrote:
> On Sun, Jun 16, 2024 at 05:50:59PM GMT, Gaurav Kashyap wrote:
> > Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
> > management hardware called Hardware Key Manager (HWKM).
> > This patch integrates HWKM support in ICE when it is available. HWKM
> > primarily provides hardware wrapped key support where the ICE
> > (storage) keys are not available in software and 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, standard keys have to
> > be used without using HWKM. Hence, providing a toggle controlled by a
> > devicetree entry to use HWKM or not.
> >
> > Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> > Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> > ---
> >  drivers/soc/qcom/ice.c | 153
> +++++++++++++++++++++++++++++++++++++++--
> >  include/soc/qcom/ice.h |   1 +
> >  2 files changed, 150 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c index
> > 6f941d32fffb..d5e74cf2946b 100644
> > --- a/drivers/soc/qcom/ice.c
> > +++ b/drivers/soc/qcom/ice.c
> > @@ -26,6 +26,40 @@
> >  #define QCOM_ICE_REG_FUSE_SETTING            0x0010
> >  #define QCOM_ICE_REG_BIST_STATUS             0x0070
> >  #define QCOM_ICE_REG_ADVANCED_CONTROL                0x1000
> > +#define QCOM_ICE_REG_CONTROL                 0x0
> > +/* QCOM ICE HWKM registers */
> > +#define QCOM_ICE_REG_HWKM_TZ_KM_CTL                  0x1000
> > +#define QCOM_ICE_REG_HWKM_TZ_KM_STATUS                       0x1004
> > +#define QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS     0x2008
> > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_0                       0x5000
> > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_1                       0x5004
> > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_2                       0x5008
> > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_3                       0x500C
> > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_4                       0x5010
> > +
> > +/* QCOM ICE HWKM reg vals */
> > +#define QCOM_ICE_HWKM_BIST_DONE_V1           BIT(16)
> > +#define QCOM_ICE_HWKM_BIST_DONE_V2           BIT(9)
> > +#define QCOM_ICE_HWKM_BIST_DONE(ver)
> QCOM_ICE_HWKM_BIST_DONE_V##ver
> > +
> > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V1            BIT(14)
> > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V2            BIT(7)
> > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v)
> QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V##v
> > +
> > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE            BIT(2)
> > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE            BIT(1)
> > +#define QCOM_ICE_HWKM_KT_CLEAR_DONE                  BIT(0)
> > +
> > +#define QCOM_ICE_HWKM_BIST_VAL(v)
> (QCOM_ICE_HWKM_BIST_DONE(v) |           \
> > +                                     QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v) |     \
> > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE |     \
> > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE |     \
> > +                                     QCOM_ICE_HWKM_KT_CLEAR_DONE)
> > +
> > +#define QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL   (BIT(0) | BIT(1)
> | BIT(2))
> > +#define QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK
> GENMASK(31, 1) #define
> > +QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL (BIT(1) | BIT(2))
> > +#define QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL     BIT(3)
> >
> >  /* BIST ("built-in self-test") status flags */
> >  #define QCOM_ICE_BIST_STATUS_MASK            GENMASK(31, 28)
> > @@ -34,6 +68,9 @@
> >  #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK  0x2  #define
> > QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK  0x4
> >
> > +#define QCOM_ICE_HWKM_REG_OFFSET     0x8000
> > +#define HWKM_OFFSET(reg)             ((reg) +
> QCOM_ICE_HWKM_REG_OFFSET)
> > +
> >  #define qcom_ice_writel(engine, val, reg)    \
> >       writel((val), (engine)->base + (reg))
> >
> > @@ -46,6 +83,9 @@ struct qcom_ice {
> >       struct device_link *link;
> >
> >       struct clk *core_clk;
> > +     u8 hwkm_version;
> > +     bool use_hwkm;
> > +     bool hwkm_init_complete;
> >  };
> >
> >  static bool qcom_ice_check_supported(struct qcom_ice *ice) @@ -63,8
> > +103,21 @@ static bool qcom_ice_check_supported(struct qcom_ice *ice)
> >               return false;
> >       }
> >
> > -     dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
> > -              major, minor, step);
> > +     if (major >= 4 || (major == 3 && minor == 2 && step >= 1))
> > +             ice->hwkm_version = 2;
> > +     else if (major == 3 && minor == 2)
> > +             ice->hwkm_version = 1;
> > +     else
> > +             ice->hwkm_version = 0;
> > +
> > +     if (ice->hwkm_version == 0)
> > +             ice->use_hwkm = false;
> > +
> > +     dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d,
> HWKM v%d\n",
> > +              major, minor, step, ice->hwkm_version);
> > +
> > +     if (!ice->use_hwkm)
> > +             dev_info(dev, "QC ICE HWKM (Hardware Key Manager) not
> > + used/supported");
> >
> >       /* If fuses are blown, ICE might not work in the standard way. */
> >       regval = qcom_ice_readl(ice, QCOM_ICE_REG_FUSE_SETTING); @@
> > -113,27 +166,106 @@ static void qcom_ice_optimization_enable(struct
> qcom_ice *ice)
> >   * fails, so we needn't do it in software too, and (c) properly testing
> >   * storage encryption requires testing the full storage stack anyway,
> >   * and not relying on hardware-level self-tests.
> > + *
> > + * However, we still care about if HWKM BIST failed (when supported)
> > + as
> > + * important functionality would fail later, so disable hwkm on failure.
> >   */
> >  static int qcom_ice_wait_bist_status(struct qcom_ice *ice)  {
> >       u32 regval;
> > +     u32 bist_done_val;
> >       int err;
> >
> >       err = readl_poll_timeout(ice->base + QCOM_ICE_REG_BIST_STATUS,
> >                                regval, !(regval & QCOM_ICE_BIST_STATUS_MASK),
> >                                50, 5000);
> > -     if (err)
> > +     if (err) {
> >               dev_err(ice->dev, "Timed out waiting for ICE self-test
> > to complete\n");
> > +             return err;
> > +     }
> >
> > +     if (ice->use_hwkm) {
> > +             bist_done_val = ice->hwkm_version == 1 ?
> > +                             QCOM_ICE_HWKM_BIST_VAL(1) :
> > +                             QCOM_ICE_HWKM_BIST_VAL(2);
> > +             if (qcom_ice_readl(ice,
> > +
> HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_STATUS)) !=
> > +                                bist_done_val) {
> > +                     dev_err(ice->dev, "HWKM BIST error\n");
> > +                     ice->use_hwkm = false;
> > +                     err = -ENODEV;
> > +             }
> > +     }
> >       return err;
> >  }
> >
> > +static void qcom_ice_enable_standard_mode(struct qcom_ice *ice) {
> > +     u32 val = 0;
> > +
> > +     /*
> > +      * When ICE is in standard (hwkm) mode, it supports HW wrapped
> > +      * keys, and when it is in legacy mode, it only supports standard
> > +      * (non HW wrapped) keys.
> 
> I can't say this is very logical.
> 
> standard mode => HW wrapped keys
> legacy mode => standard keys
> 
> Consider changing the terms.
> 

Ack, will make this clearer

> > +      *
> > +      * Put ICE in standard mode, ICE defaults to legacy mode.
> > +      * Legacy mode - ICE HWKM slave not supported.
> > +      * Standard mode - ICE HWKM slave supported.
> 
> s/slave/some other term/
> 
Ack - will address this.

> Is it possible to use both kind of keys when working on standard mode?
> If not, it should be the user who selects what type of keys to be used.
> Enforcing this via DT is not a way to go.
> 

Unfortunately, that support is not there yet. When you say user, do you mean to have it as a filesystem
mount option?

The way the UFS/EMMC crypto layer is designed currently is that, this information
is needed when the modules are loaded.
https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org/#Z31drivers:ufs:core:ufshcd-crypto.c

I am thinking of a way now to do this with DT, but without having a new vendor property.
Is it acceptable to use the addressable range as the deciding factor? Say use legacy mode of ICE
when the addressable size is 0x8000 and use HWKM mode of ICE when the addressable size is
0x10000.

> > +      *
> > +      * Depending on the version of HWKM, it is controlled by different
> > +      * registers in ICE.
> > +      */
> > +     if (ice->hwkm_version >= 2) {
> > +             val = qcom_ice_readl(ice, QCOM_ICE_REG_CONTROL);
> > +             val = val & QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK;
> > +             qcom_ice_writel(ice, val, QCOM_ICE_REG_CONTROL);
> > +     } else {
> > +             qcom_ice_writel(ice,
> QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL,
> > +                             HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_CTL));
> > +     }
> > +}
> > +
> > +static void qcom_ice_hwkm_init(struct qcom_ice *ice) {
> > +     /* Disable CRC checks. This HWKM feature is not used. */
> > +     qcom_ice_writel(ice, QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL,
> > +                     HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_CTL));
> > +
> > +     /*
> > +      * Give register bank of the HWKM slave access to read and modify
> > +      * the keyslots in ICE HWKM slave. Without this, trustzone will not
> > +      * be able to program keys into ICE.
> > +      */
> > +     qcom_ice_writel(ice, GENMASK(31, 0),
> HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_0));
> > +     qcom_ice_writel(ice, GENMASK(31, 0),
> HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_1));
> > +     qcom_ice_writel(ice, GENMASK(31, 0),
> HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_2));
> > +     qcom_ice_writel(ice, GENMASK(31, 0),
> HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_3));
> > +     qcom_ice_writel(ice, GENMASK(31, 0),
> > + HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BBAC_4));
> > +
> > +     /* Clear HWKM response FIFO before doing anything */
> > +     qcom_ice_writel(ice, QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL,
> > +
> HWKM_OFFSET(QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS));
> > +     ice->hwkm_init_complete = true;
> > +}
> > +
> >  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);
> >
> > @@ -149,6 +281,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);
> > @@ -156,6 +292,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;
> >  }
> > @@ -205,6 +342,12 @@ int qcom_ice_evict_key(struct qcom_ice *ice, int
> > slot)  }  EXPORT_SYMBOL_GPL(qcom_ice_evict_key);
> >
> 
> Documentation?
> 
> > +bool qcom_ice_hwkm_supported(struct qcom_ice *ice)
> > +{
> > +     return ice->use_hwkm;
> 
> I see that use_hwkm can change during runtime. Will it have an impact on
> a driver that calls this first?
> 
> > +}
> > +EXPORT_SYMBOL_GPL(qcom_ice_hwkm_supported);
> > +
> >  static struct qcom_ice *qcom_ice_create(struct device *dev,
> >                                       void __iomem *base)
> >  {
> > @@ -239,6 +382,8 @@ 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 = of_property_read_bool(dev->of_node,
> > +                                              "qcom,ice-use-hwkm");
> 
> DT bindings should come before driver changes.
> 
> >
> >       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
> >
> 
> --
> With best wishes
> Dmitry

Regards,
Gaurav

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap (QUIC)]

Hello Neil,

On 06/18/2024 12:14 AM PDT, Neil Armstrong wrote:
> On 17/06/2024 02:50, Gaurav Kashyap wrote:
> > Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
> > management hardware called Hardware Key Manager (HWKM).
> > This patch integrates HWKM support in ICE when it is available. HWKM
> > primarily provides hardware wrapped key support where the ICE
> > (storage) keys are not available in software and 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, standard keys have to
> > be used without using HWKM. Hence, providing a toggle controlled by a
> > devicetree entry to use HWKM or not.
> >
> > Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> > Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> > ---
> >   drivers/soc/qcom/ice.c | 153
> +++++++++++++++++++++++++++++++++++++++--
> >   include/soc/qcom/ice.h |   1 +
> >   2 files changed, 150 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c index
> > 6f941d32fffb..d5e74cf2946b 100644
> > --- a/drivers/soc/qcom/ice.c
> > +++ b/drivers/soc/qcom/ice.c
> > @@ -26,6 +26,40 @@
> 
> <snip>
> 
> > +
> >   static struct qcom_ice *qcom_ice_create(struct device *dev,
> >                                       void __iomem *base)
> >   {
> > @@ -239,6 +382,8 @@ 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 = of_property_read_bool(dev->of_node,
> > +                                              "qcom,ice-use-hwkm");
> 
> Please drop this property and instead add an scm function calling:
> 
> __qcom_scm_is_call_available(QCOM_SCM_SVC_ES,
> QCOM_SCM_ES_DERIVE_SW_SECRET)
> 
> like
> 
> bool qcom_scm_derive_sw_secret_available(void)
> {
>         if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
>                                           QCOM_SCM_ES_DERIVE_SW_SECRET))
>                 return false;
> 
>         return true;
> }
> 
> You may perhaps only call qcom_scm_derive_sw_secret_available() for
> some ICE versions.
> 
> Neil

The issue here is that for the same ICE version, based on the chipset,
there might be different configurations.

Is it acceptable to use the addressable size from DTSI instead?
Meaning, if it 0x8000, it would take the legacy route, and only when it has been
updated to 0x10000, we would use HWKM and wrapped keys.

> 
> >
> >       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__ */

Regards,
Gaurav

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Wed, 19 Jun 2024 at 01:07, Gaurav Kashyap (QUIC)
<quic_gaurkash@quicinc.com> wrote:
>
> Hello Dmitry,
>
> On 06/17/2024 12:55 AM PDT, Dmitry Baryshkov wrote:
> > On Sun, Jun 16, 2024 at 05:50:59PM GMT, Gaurav Kashyap wrote:
> > > Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
> > > management hardware called Hardware Key Manager (HWKM).
> > > This patch integrates HWKM support in ICE when it is available. HWKM
> > > primarily provides hardware wrapped key support where the ICE
> > > (storage) keys are not available in software and 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, standard keys have to
> > > be used without using HWKM. Hence, providing a toggle controlled by a
> > > devicetree entry to use HWKM or not.
> > >
> > > Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> > > Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> > > ---
> > >  drivers/soc/qcom/ice.c | 153
> > +++++++++++++++++++++++++++++++++++++++--
> > >  include/soc/qcom/ice.h |   1 +
> > >  2 files changed, 150 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c index
> > > 6f941d32fffb..d5e74cf2946b 100644
> > > --- a/drivers/soc/qcom/ice.c
> > > +++ b/drivers/soc/qcom/ice.c
> > > @@ -26,6 +26,40 @@
> > >  #define QCOM_ICE_REG_FUSE_SETTING            0x0010
> > >  #define QCOM_ICE_REG_BIST_STATUS             0x0070
> > >  #define QCOM_ICE_REG_ADVANCED_CONTROL                0x1000
> > > +#define QCOM_ICE_REG_CONTROL                 0x0
> > > +/* QCOM ICE HWKM registers */
> > > +#define QCOM_ICE_REG_HWKM_TZ_KM_CTL                  0x1000
> > > +#define QCOM_ICE_REG_HWKM_TZ_KM_STATUS                       0x1004
> > > +#define QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS     0x2008
> > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_0                       0x5000
> > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_1                       0x5004
> > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_2                       0x5008
> > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_3                       0x500C
> > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_4                       0x5010
> > > +
> > > +/* QCOM ICE HWKM reg vals */
> > > +#define QCOM_ICE_HWKM_BIST_DONE_V1           BIT(16)
> > > +#define QCOM_ICE_HWKM_BIST_DONE_V2           BIT(9)
> > > +#define QCOM_ICE_HWKM_BIST_DONE(ver)
> > QCOM_ICE_HWKM_BIST_DONE_V##ver
> > > +
> > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V1            BIT(14)
> > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V2            BIT(7)
> > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v)
> > QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V##v
> > > +
> > > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE            BIT(2)
> > > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE            BIT(1)
> > > +#define QCOM_ICE_HWKM_KT_CLEAR_DONE                  BIT(0)
> > > +
> > > +#define QCOM_ICE_HWKM_BIST_VAL(v)
> > (QCOM_ICE_HWKM_BIST_DONE(v) |           \
> > > +                                     QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v) |     \
> > > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE |     \
> > > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE |     \
> > > +                                     QCOM_ICE_HWKM_KT_CLEAR_DONE)
> > > +
> > > +#define QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL   (BIT(0) | BIT(1)
> > | BIT(2))
> > > +#define QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK
> > GENMASK(31, 1) #define
> > > +QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL (BIT(1) | BIT(2))
> > > +#define QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL     BIT(3)
> > >
> > >  /* BIST ("built-in self-test") status flags */
> > >  #define QCOM_ICE_BIST_STATUS_MASK            GENMASK(31, 28)
> > > @@ -34,6 +68,9 @@
> > >  #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK  0x2  #define
> > > QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK  0x4
> > >
> > > +#define QCOM_ICE_HWKM_REG_OFFSET     0x8000
> > > +#define HWKM_OFFSET(reg)             ((reg) +
> > QCOM_ICE_HWKM_REG_OFFSET)
> > > +
> > >  #define qcom_ice_writel(engine, val, reg)    \
> > >       writel((val), (engine)->base + (reg))
> > >
> > > @@ -46,6 +83,9 @@ struct qcom_ice {
> > >       struct device_link *link;
> > >
> > >       struct clk *core_clk;
> > > +     u8 hwkm_version;
> > > +     bool use_hwkm;
> > > +     bool hwkm_init_complete;
> > >  };
> > >
> > >  static bool qcom_ice_check_supported(struct qcom_ice *ice) @@ -63,8
> > > +103,21 @@ static bool qcom_ice_check_supported(struct qcom_ice *ice)
> > >               return false;
> > >       }
> > >
> > > -     dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
> > > -              major, minor, step);
> > > +     if (major >= 4 || (major == 3 && minor == 2 && step >= 1))
> > > +             ice->hwkm_version = 2;
> > > +     else if (major == 3 && minor == 2)
> > > +             ice->hwkm_version = 1;
> > > +     else
> > > +             ice->hwkm_version = 0;
> > > +
> > > +     if (ice->hwkm_version == 0)
> > > +             ice->use_hwkm = false;
> > > +
> > > +     dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d,
> > HWKM v%d\n",
> > > +              major, minor, step, ice->hwkm_version);
> > > +
> > > +     if (!ice->use_hwkm)
> > > +             dev_info(dev, "QC ICE HWKM (Hardware Key Manager) not
> > > + used/supported");
> > >
> > >       /* If fuses are blown, ICE might not work in the standard way. */
> > >       regval = qcom_ice_readl(ice, QCOM_ICE_REG_FUSE_SETTING); @@
> > > -113,27 +166,106 @@ static void qcom_ice_optimization_enable(struct
> > qcom_ice *ice)
> > >   * fails, so we needn't do it in software too, and (c) properly testing
> > >   * storage encryption requires testing the full storage stack anyway,
> > >   * and not relying on hardware-level self-tests.
> > > + *
> > > + * However, we still care about if HWKM BIST failed (when supported)
> > > + as
> > > + * important functionality would fail later, so disable hwkm on failure.
> > >   */
> > >  static int qcom_ice_wait_bist_status(struct qcom_ice *ice)  {
> > >       u32 regval;
> > > +     u32 bist_done_val;
> > >       int err;
> > >
> > >       err = readl_poll_timeout(ice->base + QCOM_ICE_REG_BIST_STATUS,
> > >                                regval, !(regval & QCOM_ICE_BIST_STATUS_MASK),
> > >                                50, 5000);
> > > -     if (err)
> > > +     if (err) {
> > >               dev_err(ice->dev, "Timed out waiting for ICE self-test
> > > to complete\n");
> > > +             return err;
> > > +     }
> > >
> > > +     if (ice->use_hwkm) {
> > > +             bist_done_val = ice->hwkm_version == 1 ?
> > > +                             QCOM_ICE_HWKM_BIST_VAL(1) :
> > > +                             QCOM_ICE_HWKM_BIST_VAL(2);
> > > +             if (qcom_ice_readl(ice,
> > > +
> > HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_STATUS)) !=
> > > +                                bist_done_val) {
> > > +                     dev_err(ice->dev, "HWKM BIST error\n");
> > > +                     ice->use_hwkm = false;
> > > +                     err = -ENODEV;
> > > +             }
> > > +     }
> > >       return err;
> > >  }
> > >
> > > +static void qcom_ice_enable_standard_mode(struct qcom_ice *ice) {
> > > +     u32 val = 0;
> > > +
> > > +     /*
> > > +      * When ICE is in standard (hwkm) mode, it supports HW wrapped
> > > +      * keys, and when it is in legacy mode, it only supports standard
> > > +      * (non HW wrapped) keys.
> >
> > I can't say this is very logical.
> >
> > standard mode => HW wrapped keys
> > legacy mode => standard keys
> >
> > Consider changing the terms.
> >
>
> Ack, will make this clearer
>
> > > +      *
> > > +      * Put ICE in standard mode, ICE defaults to legacy mode.
> > > +      * Legacy mode - ICE HWKM slave not supported.
> > > +      * Standard mode - ICE HWKM slave supported.
> >
> > s/slave/some other term/
> >
> Ack - will address this.
>
> > Is it possible to use both kind of keys when working on standard mode?
> > If not, it should be the user who selects what type of keys to be used.
> > Enforcing this via DT is not a way to go.
> >
>
> Unfortunately, that support is not there yet. When you say user, do you mean to have it as a filesystem
> mount option?

During cryptsetup time. When running e.g. cryptsetup I, as a user,
would like to be able to use either a hardware-wrapped key or a
standard key.

> The way the UFS/EMMC crypto layer is designed currently is that, this information
> is needed when the modules are loaded.
>
> https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org/#Z31drivers:ufs:core:ufshcd-crypto.c

I see that the driver lists capabilities here. E.g. that it supports
HW-wrapped keys. But the line doesn't specify that standard keys are
not supported.

Also, I'd have expected that hw-wrapped keys are handled using trusted
keys mechanism (see security/keys/trusted-keys/). Could you please
point out why that's not the case?

> I am thinking of a way now to do this with DT, but without having a new vendor property.
> Is it acceptable to use the addressable range as the deciding factor? Say use legacy mode of ICE
> when the addressable size is 0x8000 and use HWKM mode of ICE when the addressable size is
> 0x10000.

Definitely, this is a NAK. It's a very unobvious hack. You have been
asked to use compatible strings to detect whether HW keys are
supported or not.

-- 
With best wishes
Dmitry

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Krzysztof Kozlowski]

On 19/06/2024 00:08, Gaurav Kashyap (QUIC) wrote:
>>
>> You may perhaps only call qcom_scm_derive_sw_secret_available() for
>> some ICE versions.
>>
>> Neil
> 
> The issue here is that for the same ICE version, based on the chipset,
> there might be different configurations.

That's not what your DTS said. To remind: your DTS said that all SM8550
and all SM8650 have it. Choice is obvious then: it's deducible from
compatible.

I still do not understand why your call cannot return you correct
"configuration".

> 
> Is it acceptable to use the addressable size from DTSI instead?
> Meaning, if it 0x8000, it would take the legacy route, and only when it has been
> updated to 0x10000, we would use HWKM and wrapped keys.

No.

Best regards,
Krzysztof

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Neil Armstrong]

Le 19/06/2024 à 00:08, Gaurav Kashyap (QUIC) a écrit :
> Hello Neil,
> 
> On 06/18/2024 12:14 AM PDT, Neil Armstrong wrote:
>> On 17/06/2024 02:50, Gaurav Kashyap wrote:
>>> Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
>>> management hardware called Hardware Key Manager (HWKM).
>>> This patch integrates HWKM support in ICE when it is available. HWKM
>>> primarily provides hardware wrapped key support where the ICE
>>> (storage) keys are not available in software and 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, standard keys have to
>>> be used without using HWKM. Hence, providing a toggle controlled by a
>>> devicetree entry to use HWKM or not.
>>>
>>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
>>> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
>>> ---
>>>    drivers/soc/qcom/ice.c | 153
>> +++++++++++++++++++++++++++++++++++++++--
>>>    include/soc/qcom/ice.h |   1 +
>>>    2 files changed, 150 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c index
>>> 6f941d32fffb..d5e74cf2946b 100644
>>> --- a/drivers/soc/qcom/ice.c
>>> +++ b/drivers/soc/qcom/ice.c
>>> @@ -26,6 +26,40 @@
>>
>> <snip>
>>
>>> +
>>>    static struct qcom_ice *qcom_ice_create(struct device *dev,
>>>                                        void __iomem *base)
>>>    {
>>> @@ -239,6 +382,8 @@ 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 = of_property_read_bool(dev->of_node,
>>> +                                              "qcom,ice-use-hwkm");
>>
>> Please drop this property and instead add an scm function calling:
>>
>> __qcom_scm_is_call_available(QCOM_SCM_SVC_ES,
>> QCOM_SCM_ES_DERIVE_SW_SECRET)
>>
>> like
>>
>> bool qcom_scm_derive_sw_secret_available(void)
>> {
>>          if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
>>                                            QCOM_SCM_ES_DERIVE_SW_SECRET))
>>                  return false;
>>
>>          return true;
>> }
>>
>> You may perhaps only call qcom_scm_derive_sw_secret_available() for
>> some ICE versions.
>>
>> Neil
> 
> The issue here is that for the same ICE version, based on the chipset,
> there might be different configurations.

So use a combination of a list of compatible strings + qcom_scm_derive_sw_secret_available()
to enable hwkm.

Neil

> 
> Is it acceptable to use the addressable size from DTSI instead?
> Meaning, if it 0x8000, it would take the legacy route, and only when it has been
> updated to 0x10000, we would use HWKM and wrapped keys.
> 
>>
>>>
>>>        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__ */
> 
> Regards,
> Gaurav

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap (QUIC)]

Hello Krzysztof

On 06/18/2024 11:17 PM PDT, Krzysztof Kozlowski wrote:
> On 19/06/2024 00:08, Gaurav Kashyap (QUIC) wrote:
> >>
> >> You may perhaps only call qcom_scm_derive_sw_secret_available() for
> >> some ICE versions.
> >>
> >> Neil
> >
> > The issue here is that for the same ICE version, based on the chipset,
> > there might be different configurations.
> 
> That's not what your DTS said. To remind: your DTS said that all SM8550 and
> all SM8650 have it. Choice is obvious then: it's deducible from compatible.
> 
> I still do not understand why your call cannot return you correct
> "configuration".
> 

ICE version and chipsets are disjoint, meaning for the same ICE HW present in SM8650 vs SMxxxx target,
SM8650 will have necessary TZ support, but SM8xxxx may not, that is the reason I was trying to indicate all SM8550 and
SM8650 have the necessary TZ support. There might have been a miscommunication there.

However , availability of QCOM_SCM_ES_GENERATE_ICE_KEY will directly translate to having the necessary firmware support.
So, I will pursue going that route and upload another set of patches to remove the DT property.

> >
> > Is it acceptable to use the addressable size from DTSI instead?
> > Meaning, if it 0x8000, it would take the legacy route, and only when
> > it has been updated to 0x10000, we would use HWKM and wrapped keys.
> 
> No.
>

Ack

> Best regards,
> Krzysztof

Regards,
Gaurav

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap (QUIC)]

On 06/19/2024 12:12 AM PDT, Neil Armstrong wrote:
> Le 19/06/2024 à 00:08, Gaurav Kashyap (QUIC) a écrit :
> > Hello Neil,
> >
> > On 06/18/2024 12:14 AM PDT, Neil Armstrong wrote:
> >> On 17/06/2024 02:50, Gaurav Kashyap wrote:
> >>> Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
> >>> management hardware called Hardware Key Manager (HWKM).
> >>> This patch integrates HWKM support in ICE when it is available. HWKM
> >>> primarily provides hardware wrapped key support where the ICE
> >>> (storage) keys are not available in software and 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, standard keys have to
> >>> be used without using HWKM. Hence, providing a toggle controlled by
> >>> a devicetree entry to use HWKM or not.
> >>>
> >>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> >>> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> >>> ---
> >>>    drivers/soc/qcom/ice.c | 153
> >> +++++++++++++++++++++++++++++++++++++++--
> >>>    include/soc/qcom/ice.h |   1 +
> >>>    2 files changed, 150 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c index
> >>> 6f941d32fffb..d5e74cf2946b 100644
> >>> --- a/drivers/soc/qcom/ice.c
> >>> +++ b/drivers/soc/qcom/ice.c
> >>> @@ -26,6 +26,40 @@
> >>
> >> <snip>
> >>
> >>> +
> >>>    static struct qcom_ice *qcom_ice_create(struct device *dev,
> >>>                                        void __iomem *base)
> >>>    {
> >>> @@ -239,6 +382,8 @@ 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 = of_property_read_bool(dev->of_node,
> >>> +                                              "qcom,ice-use-hwkm");
> >>
> >> Please drop this property and instead add an scm function calling:
> >>
> >> __qcom_scm_is_call_available(QCOM_SCM_SVC_ES,
> >> QCOM_SCM_ES_DERIVE_SW_SECRET)
> >>
> >> like
> >>
> >> bool qcom_scm_derive_sw_secret_available(void)
> >> {
> >>          if (!__qcom_scm_is_call_available(__scm->dev,
> QCOM_SCM_SVC_ES,
> >>                                            QCOM_SCM_ES_DERIVE_SW_SECRET))
> >>                  return false;
> >>
> >>          return true;
> >> }
> >>
> >> You may perhaps only call qcom_scm_derive_sw_secret_available() for
> >> some ICE versions.
> >>
> >> Neil
> >
> > The issue here is that for the same ICE version, based on the chipset,
> > there might be different configurations.
> 
> So use a combination of a list of compatible strings +
> qcom_scm_derive_sw_secret_available()
> to enable hwkm.
> 
> Neil
>

Okay, that makes sense to me, I will try that.
In fact, looking for only QCOM_SCM_ES_GENERATE_ICE_KEY instead of SW_SECRET works better.
And would work even without compatible strings.
As availability of QCOM_SCM_ES_GENERATE_ICE_KEY will correlate with TZ/firmware having the necessary support.

> >
> > Is it acceptable to use the addressable size from DTSI instead?
> > Meaning, if it 0x8000, it would take the legacy route, and only when
> > it has been updated to 0x10000, we would use HWKM and wrapped keys.
> >
> >>
> >>>
> >>>        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__ */
> >
> > Regards,
> > Gaurav

Regards,
Gaurav

RE: [PATCH v5 13/15] dt-bindings: crypto: ice: document the hwkm property

[Gaurav Kashyap (QUIC)]

On 06/17/2024 11:31 PM PDT, Krzysztof Kozlowski wrote:
> On 18/06/2024 02:35, Gaurav Kashyap (QUIC) wrote:
> > Hello Krzysztof
> >
> > On   06/17/2024 12:17 AM PDT, Krzysztof Kozlowski wrote:
> >> On 17/06/2024 02:51, Gaurav Kashyap wrote:
> >>> +  qcom,ice-use-hwkm:
> >>> +    type: boolean
> >>> +    description:
> >>> +      Use the supported Hardware Key Manager (HWKM) in Qualcomm
> ICE
> >>> +      to support wrapped keys. Having this entry helps scenarios where
> >>> +      the ICE hardware supports HWKM, but the Trustzone firmware does
> >>> +      not have the full capability to use this HWKM and support wrapped
> >>> +      keys. Not having this entry enabled would make ICE function in
> >>> +      non-HWKM mode supporting standard keys.
> >>
> >> No changelog, previous comments and discussion ignored.
> >>
> >> NAK
> >
> > Apologies for not addressing the previous comments.
> > https://lore.kernel.org/all/9892c541ba4e4b5d975faaa4b49c92ba@quicinc.c
> > om/
> >
> > Maybe we can continue our discussion here; " SM8450 and SM8350 QCOM
> > ICE both support HWKM in their ICE hardware.
> > However, wrapped keys can not be enabled on those targets due to
> > certain missing trustzone support. If we solely rely on hardware
> > version to decide if ICE has to use wrapped keys for data encryption,
> > then it becomes untestable on those chipsets.
> 
> That does not make any sense to me. You enable it for SM8550 and SM8650
> not SM8450 and SM8350.
> 
> >
> > So, we want another way to distinguish this scenario, and hence I
> > chose a DT vendor property
> 
> What scenario? Show it in your patches.
> 
> > to explicitly mention if we have to use the supported HWKM.
> > If there is another way, I am open to exploring that as well."
> 
> That property is just entirely redundant. If you claim otherwise, show it
> through patches.
> 
> To be clear, so you will not resend the same ignoring comments: NAK.
> 

Ack, next set of patches will have the property removed.

> Best regards,
> Krzysztof

Regards,
Gaurav

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap (QUIC)]

Hello Dmitry

On 06/18/2024 3:17 PM PDT, Dmitry Baryshkov wrote:
> On Wed, 19 Jun 2024 at 01:07, Gaurav Kashyap (QUIC)
> <quic_gaurkash@quicinc.com> wrote:
> >
> > Hello Dmitry,
> >
> > On 06/17/2024 12:55 AM PDT, Dmitry Baryshkov wrote:
> > > On Sun, Jun 16, 2024 at 05:50:59PM GMT, Gaurav Kashyap wrote:
> > > > Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
> > > > management hardware called Hardware Key Manager (HWKM).
> > > > This patch integrates HWKM support in ICE when it is available.
> > > > HWKM primarily provides hardware wrapped key support where the
> ICE
> > > > (storage) keys are not available in software and 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, standard keys have to be used without using HWKM. Hence,
> > > > providing a toggle controlled by a devicetree entry to use HWKM or not.
> > > >
> > > > Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> > > > Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> > > > ---
> > > >  drivers/soc/qcom/ice.c | 153
> > > +++++++++++++++++++++++++++++++++++++++--
> > > >  include/soc/qcom/ice.h |   1 +
> > > >  2 files changed, 150 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c index
> > > > 6f941d32fffb..d5e74cf2946b 100644
> > > > --- a/drivers/soc/qcom/ice.c
> > > > +++ b/drivers/soc/qcom/ice.c
> > > > @@ -26,6 +26,40 @@
> > > >  #define QCOM_ICE_REG_FUSE_SETTING            0x0010
> > > >  #define QCOM_ICE_REG_BIST_STATUS             0x0070
> > > >  #define QCOM_ICE_REG_ADVANCED_CONTROL                0x1000
> > > > +#define QCOM_ICE_REG_CONTROL                 0x0
> > > > +/* QCOM ICE HWKM registers */
> > > > +#define QCOM_ICE_REG_HWKM_TZ_KM_CTL                  0x1000
> > > > +#define QCOM_ICE_REG_HWKM_TZ_KM_STATUS                       0x1004
> > > > +#define QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS
> 0x2008
> > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_0                       0x5000
> > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_1                       0x5004
> > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_2                       0x5008
> > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_3                       0x500C
> > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_4                       0x5010
> > > > +
> > > > +/* QCOM ICE HWKM reg vals */
> > > > +#define QCOM_ICE_HWKM_BIST_DONE_V1           BIT(16)
> > > > +#define QCOM_ICE_HWKM_BIST_DONE_V2           BIT(9)
> > > > +#define QCOM_ICE_HWKM_BIST_DONE(ver)
> > > QCOM_ICE_HWKM_BIST_DONE_V##ver
> > > > +
> > > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V1            BIT(14)
> > > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V2            BIT(7)
> > > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v)
> > > QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V##v
> > > > +
> > > > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE            BIT(2)
> > > > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE            BIT(1)
> > > > +#define QCOM_ICE_HWKM_KT_CLEAR_DONE                  BIT(0)
> > > > +
> > > > +#define QCOM_ICE_HWKM_BIST_VAL(v)
> > > (QCOM_ICE_HWKM_BIST_DONE(v) |           \
> > > > +                                     QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v) |     \
> > > > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE |     \
> > > > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE |     \
> > > > +                                     QCOM_ICE_HWKM_KT_CLEAR_DONE)
> > > > +
> > > > +#define QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL   (BIT(0) |
> BIT(1)
> > > | BIT(2))
> > > > +#define QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK
> > > GENMASK(31, 1) #define
> > > > +QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL (BIT(1) | BIT(2))
> > > > +#define QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL     BIT(3)
> > > >
> > > >  /* BIST ("built-in self-test") status flags */
> > > >  #define QCOM_ICE_BIST_STATUS_MASK            GENMASK(31, 28)
> > > > @@ -34,6 +68,9 @@
> > > >  #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK  0x2  #define
> > > > QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK  0x4
> > > >
> > > > +#define QCOM_ICE_HWKM_REG_OFFSET     0x8000
> > > > +#define HWKM_OFFSET(reg)             ((reg) +
> > > QCOM_ICE_HWKM_REG_OFFSET)
> > > > +
> > > >  #define qcom_ice_writel(engine, val, reg)    \
> > > >       writel((val), (engine)->base + (reg))
> > > >
> > > > @@ -46,6 +83,9 @@ struct qcom_ice {
> > > >       struct device_link *link;
> > > >
> > > >       struct clk *core_clk;
> > > > +     u8 hwkm_version;
> > > > +     bool use_hwkm;
> > > > +     bool hwkm_init_complete;
> > > >  };
> > > >
> > > >  static bool qcom_ice_check_supported(struct qcom_ice *ice) @@
> > > > -63,8
> > > > +103,21 @@ static bool qcom_ice_check_supported(struct qcom_ice
> > > > +*ice)
> > > >               return false;
> > > >       }
> > > >
> > > > -     dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
> > > > -              major, minor, step);
> > > > +     if (major >= 4 || (major == 3 && minor == 2 && step >= 1))
> > > > +             ice->hwkm_version = 2;
> > > > +     else if (major == 3 && minor == 2)
> > > > +             ice->hwkm_version = 1;
> > > > +     else
> > > > +             ice->hwkm_version = 0;
> > > > +
> > > > +     if (ice->hwkm_version == 0)
> > > > +             ice->use_hwkm = false;
> > > > +
> > > > +     dev_info(dev, "Found QC Inline Crypto Engine (ICE)
> > > > + v%d.%d.%d,
> > > HWKM v%d\n",
> > > > +              major, minor, step, ice->hwkm_version);
> > > > +
> > > > +     if (!ice->use_hwkm)
> > > > +             dev_info(dev, "QC ICE HWKM (Hardware Key Manager)
> > > > + not used/supported");
> > > >
> > > >       /* If fuses are blown, ICE might not work in the standard way. */
> > > >       regval = qcom_ice_readl(ice, QCOM_ICE_REG_FUSE_SETTING); @@
> > > > -113,27 +166,106 @@ static void
> > > > qcom_ice_optimization_enable(struct
> > > qcom_ice *ice)
> > > >   * fails, so we needn't do it in software too, and (c) properly testing
> > > >   * storage encryption requires testing the full storage stack anyway,
> > > >   * and not relying on hardware-level self-tests.
> > > > + *
> > > > + * However, we still care about if HWKM BIST failed (when
> > > > + supported) as
> > > > + * important functionality would fail later, so disable hwkm on failure.
> > > >   */
> > > >  static int qcom_ice_wait_bist_status(struct qcom_ice *ice)  {
> > > >       u32 regval;
> > > > +     u32 bist_done_val;
> > > >       int err;
> > > >
> > > >       err = readl_poll_timeout(ice->base +
> QCOM_ICE_REG_BIST_STATUS,
> > > >                                regval, !(regval & QCOM_ICE_BIST_STATUS_MASK),
> > > >                                50, 5000);
> > > > -     if (err)
> > > > +     if (err) {
> > > >               dev_err(ice->dev, "Timed out waiting for ICE
> > > > self-test to complete\n");
> > > > +             return err;
> > > > +     }
> > > >
> > > > +     if (ice->use_hwkm) {
> > > > +             bist_done_val = ice->hwkm_version == 1 ?
> > > > +                             QCOM_ICE_HWKM_BIST_VAL(1) :
> > > > +                             QCOM_ICE_HWKM_BIST_VAL(2);
> > > > +             if (qcom_ice_readl(ice,
> > > > +
> > > HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_STATUS)) !=
> > > > +                                bist_done_val) {
> > > > +                     dev_err(ice->dev, "HWKM BIST error\n");
> > > > +                     ice->use_hwkm = false;
> > > > +                     err = -ENODEV;
> > > > +             }
> > > > +     }
> > > >       return err;
> > > >  }
> > > >
> > > > +static void qcom_ice_enable_standard_mode(struct qcom_ice *ice) {
> > > > +     u32 val = 0;
> > > > +
> > > > +     /*
> > > > +      * When ICE is in standard (hwkm) mode, it supports HW wrapped
> > > > +      * keys, and when it is in legacy mode, it only supports standard
> > > > +      * (non HW wrapped) keys.
> > >
> > > I can't say this is very logical.
> > >
> > > standard mode => HW wrapped keys
> > > legacy mode => standard keys
> > >
> > > Consider changing the terms.
> > >
> >
> > Ack, will make this clearer
> >
> > > > +      *
> > > > +      * Put ICE in standard mode, ICE defaults to legacy mode.
> > > > +      * Legacy mode - ICE HWKM slave not supported.
> > > > +      * Standard mode - ICE HWKM slave supported.
> > >
> > > s/slave/some other term/
> > >
> > Ack - will address this.
> >
> > > Is it possible to use both kind of keys when working on standard mode?
> > > If not, it should be the user who selects what type of keys to be used.
> > > Enforcing this via DT is not a way to go.
> > >
> >
> > Unfortunately, that support is not there yet. When you say user, do
> > you mean to have it as a filesystem mount option?
> 
> During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> to be able to use either a hardware-wrapped key or a standard key.
> 

What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)

Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
And specify policies (links to keys) for different folders.

> > The way the UFS/EMMC crypto layer is designed currently is that, this
> > information is needed when the modules are loaded.
> >
> > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > /#Z31drivers:ufs:core:ufshcd-crypto.c
> 
> I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> keys. But the line doesn't specify that standard keys are not supported.
> 

Those are capabilities that are read from the storage controller. However, wrapped keys
Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
from the SoC.

QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
That is something we are internally working on, but not available yet.

> Also, I'd have expected that hw-wrapped keys are handled using trusted
> keys mechanism (see security/keys/trusted-keys/). Could you please point
> out why that's not the case?
> 

I will evaluate this.
But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
driver. The interface is through QCOM SCM driver.

> > I am thinking of a way now to do this with DT, but without having a new
> vendor property.
> > Is it acceptable to use the addressable range as the deciding factor?
> > Say use legacy mode of ICE when the addressable size is 0x8000 and use
> > HWKM mode of ICE when the addressable size is 0x10000.
> 
> Definitely, this is a NAK. It's a very unobvious hack. You have been asked to
> use compatible strings to detect whether HW keys are supported or not.
> 
> --
> With best wishes
> Dmitry

Regards,
Gaurav

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Krzysztof Kozlowski]

On 20/06/2024 00:02, Gaurav Kashyap (QUIC) wrote:
> Hello Krzysztof
> 
> On 06/18/2024 11:17 PM PDT, Krzysztof Kozlowski wrote:
>> On 19/06/2024 00:08, Gaurav Kashyap (QUIC) wrote:
>>>>
>>>> You may perhaps only call qcom_scm_derive_sw_secret_available() for
>>>> some ICE versions.
>>>>
>>>> Neil
>>>
>>> The issue here is that for the same ICE version, based on the chipset,
>>> there might be different configurations.
>>
>> That's not what your DTS said. To remind: your DTS said that all SM8550 and
>> all SM8650 have it. Choice is obvious then: it's deducible from compatible.
>>
>> I still do not understand why your call cannot return you correct
>> "configuration".
>>
> 
> ICE version and chipsets are disjoint, meaning for the same ICE HW present in SM8650 vs SMxxxx target,
> SM8650 will have necessary TZ support, but SM8xxxx may not, that is the reason I was trying to indicate all SM8550 and
> SM8650 have the necessary TZ support. There might have been a miscommunication there.

No. Read your DTS again.



Best regards,
Krzysztof

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Thu, 20 Jun 2024 at 01:30, Gaurav Kashyap (QUIC)
<quic_gaurkash@quicinc.com> wrote:
>
> Hello Dmitry
>
> On 06/18/2024 3:17 PM PDT, Dmitry Baryshkov wrote:
> > On Wed, 19 Jun 2024 at 01:07, Gaurav Kashyap (QUIC)
> > <quic_gaurkash@quicinc.com> wrote:
> > >
> > > Hello Dmitry,
> > >
> > > On 06/17/2024 12:55 AM PDT, Dmitry Baryshkov wrote:
> > > > On Sun, Jun 16, 2024 at 05:50:59PM GMT, Gaurav Kashyap wrote:
> > > > > Qualcomm's ICE (Inline Crypto Engine) contains a proprietary key
> > > > > management hardware called Hardware Key Manager (HWKM).
> > > > > This patch integrates HWKM support in ICE when it is available.
> > > > > HWKM primarily provides hardware wrapped key support where the
> > ICE
> > > > > (storage) keys are not available in software and 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, standard keys have to be used without using HWKM. Hence,
> > > > > providing a toggle controlled by a devicetree entry to use HWKM or not.
> > > > >
> > > > > Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> > > > > Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> > > > > ---
> > > > >  drivers/soc/qcom/ice.c | 153
> > > > +++++++++++++++++++++++++++++++++++++++--
> > > > >  include/soc/qcom/ice.h |   1 +
> > > > >  2 files changed, 150 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c index
> > > > > 6f941d32fffb..d5e74cf2946b 100644
> > > > > --- a/drivers/soc/qcom/ice.c
> > > > > +++ b/drivers/soc/qcom/ice.c
> > > > > @@ -26,6 +26,40 @@
> > > > >  #define QCOM_ICE_REG_FUSE_SETTING            0x0010
> > > > >  #define QCOM_ICE_REG_BIST_STATUS             0x0070
> > > > >  #define QCOM_ICE_REG_ADVANCED_CONTROL                0x1000
> > > > > +#define QCOM_ICE_REG_CONTROL                 0x0
> > > > > +/* QCOM ICE HWKM registers */
> > > > > +#define QCOM_ICE_REG_HWKM_TZ_KM_CTL                  0x1000
> > > > > +#define QCOM_ICE_REG_HWKM_TZ_KM_STATUS                       0x1004
> > > > > +#define QCOM_ICE_REG_HWKM_BANK0_BANKN_IRQ_STATUS
> > 0x2008
> > > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_0                       0x5000
> > > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_1                       0x5004
> > > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_2                       0x5008
> > > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_3                       0x500C
> > > > > +#define QCOM_ICE_REG_HWKM_BANK0_BBAC_4                       0x5010
> > > > > +
> > > > > +/* QCOM ICE HWKM reg vals */
> > > > > +#define QCOM_ICE_HWKM_BIST_DONE_V1           BIT(16)
> > > > > +#define QCOM_ICE_HWKM_BIST_DONE_V2           BIT(9)
> > > > > +#define QCOM_ICE_HWKM_BIST_DONE(ver)
> > > > QCOM_ICE_HWKM_BIST_DONE_V##ver
> > > > > +
> > > > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V1            BIT(14)
> > > > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V2            BIT(7)
> > > > > +#define QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v)
> > > > QCOM_ICE_HWKM_CRYPTO_BIST_DONE_V##v
> > > > > +
> > > > > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE            BIT(2)
> > > > > +#define QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE            BIT(1)
> > > > > +#define QCOM_ICE_HWKM_KT_CLEAR_DONE                  BIT(0)
> > > > > +
> > > > > +#define QCOM_ICE_HWKM_BIST_VAL(v)
> > > > (QCOM_ICE_HWKM_BIST_DONE(v) |           \
> > > > > +                                     QCOM_ICE_HWKM_CRYPTO_BIST_DONE(v) |     \
> > > > > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST1_DONE |     \
> > > > > +                                     QCOM_ICE_HWKM_BOOT_CMD_LIST0_DONE |     \
> > > > > +                                     QCOM_ICE_HWKM_KT_CLEAR_DONE)
> > > > > +
> > > > > +#define QCOM_ICE_HWKM_V1_STANDARD_MODE_VAL   (BIT(0) |
> > BIT(1)
> > > > | BIT(2))
> > > > > +#define QCOM_ICE_HWKM_V2_STANDARD_MODE_MASK
> > > > GENMASK(31, 1) #define
> > > > > +QCOM_ICE_HWKM_DISABLE_CRC_CHECKS_VAL (BIT(1) | BIT(2))
> > > > > +#define QCOM_ICE_HWKM_RSP_FIFO_CLEAR_VAL     BIT(3)
> > > > >
> > > > >  /* BIST ("built-in self-test") status flags */
> > > > >  #define QCOM_ICE_BIST_STATUS_MASK            GENMASK(31, 28)
> > > > > @@ -34,6 +68,9 @@
> > > > >  #define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK  0x2  #define
> > > > > QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK  0x4
> > > > >
> > > > > +#define QCOM_ICE_HWKM_REG_OFFSET     0x8000
> > > > > +#define HWKM_OFFSET(reg)             ((reg) +
> > > > QCOM_ICE_HWKM_REG_OFFSET)
> > > > > +
> > > > >  #define qcom_ice_writel(engine, val, reg)    \
> > > > >       writel((val), (engine)->base + (reg))
> > > > >
> > > > > @@ -46,6 +83,9 @@ struct qcom_ice {
> > > > >       struct device_link *link;
> > > > >
> > > > >       struct clk *core_clk;
> > > > > +     u8 hwkm_version;
> > > > > +     bool use_hwkm;
> > > > > +     bool hwkm_init_complete;
> > > > >  };
> > > > >
> > > > >  static bool qcom_ice_check_supported(struct qcom_ice *ice) @@
> > > > > -63,8
> > > > > +103,21 @@ static bool qcom_ice_check_supported(struct qcom_ice
> > > > > +*ice)
> > > > >               return false;
> > > > >       }
> > > > >
> > > > > -     dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
> > > > > -              major, minor, step);
> > > > > +     if (major >= 4 || (major == 3 && minor == 2 && step >= 1))
> > > > > +             ice->hwkm_version = 2;
> > > > > +     else if (major == 3 && minor == 2)
> > > > > +             ice->hwkm_version = 1;
> > > > > +     else
> > > > > +             ice->hwkm_version = 0;
> > > > > +
> > > > > +     if (ice->hwkm_version == 0)
> > > > > +             ice->use_hwkm = false;
> > > > > +
> > > > > +     dev_info(dev, "Found QC Inline Crypto Engine (ICE)
> > > > > + v%d.%d.%d,
> > > > HWKM v%d\n",
> > > > > +              major, minor, step, ice->hwkm_version);
> > > > > +
> > > > > +     if (!ice->use_hwkm)
> > > > > +             dev_info(dev, "QC ICE HWKM (Hardware Key Manager)
> > > > > + not used/supported");
> > > > >
> > > > >       /* If fuses are blown, ICE might not work in the standard way. */
> > > > >       regval = qcom_ice_readl(ice, QCOM_ICE_REG_FUSE_SETTING); @@
> > > > > -113,27 +166,106 @@ static void
> > > > > qcom_ice_optimization_enable(struct
> > > > qcom_ice *ice)
> > > > >   * fails, so we needn't do it in software too, and (c) properly testing
> > > > >   * storage encryption requires testing the full storage stack anyway,
> > > > >   * and not relying on hardware-level self-tests.
> > > > > + *
> > > > > + * However, we still care about if HWKM BIST failed (when
> > > > > + supported) as
> > > > > + * important functionality would fail later, so disable hwkm on failure.
> > > > >   */
> > > > >  static int qcom_ice_wait_bist_status(struct qcom_ice *ice)  {
> > > > >       u32 regval;
> > > > > +     u32 bist_done_val;
> > > > >       int err;
> > > > >
> > > > >       err = readl_poll_timeout(ice->base +
> > QCOM_ICE_REG_BIST_STATUS,
> > > > >                                regval, !(regval & QCOM_ICE_BIST_STATUS_MASK),
> > > > >                                50, 5000);
> > > > > -     if (err)
> > > > > +     if (err) {
> > > > >               dev_err(ice->dev, "Timed out waiting for ICE
> > > > > self-test to complete\n");
> > > > > +             return err;
> > > > > +     }
> > > > >
> > > > > +     if (ice->use_hwkm) {
> > > > > +             bist_done_val = ice->hwkm_version == 1 ?
> > > > > +                             QCOM_ICE_HWKM_BIST_VAL(1) :
> > > > > +                             QCOM_ICE_HWKM_BIST_VAL(2);
> > > > > +             if (qcom_ice_readl(ice,
> > > > > +
> > > > HWKM_OFFSET(QCOM_ICE_REG_HWKM_TZ_KM_STATUS)) !=
> > > > > +                                bist_done_val) {
> > > > > +                     dev_err(ice->dev, "HWKM BIST error\n");
> > > > > +                     ice->use_hwkm = false;
> > > > > +                     err = -ENODEV;
> > > > > +             }
> > > > > +     }
> > > > >       return err;
> > > > >  }
> > > > >
> > > > > +static void qcom_ice_enable_standard_mode(struct qcom_ice *ice) {
> > > > > +     u32 val = 0;
> > > > > +
> > > > > +     /*
> > > > > +      * When ICE is in standard (hwkm) mode, it supports HW wrapped
> > > > > +      * keys, and when it is in legacy mode, it only supports standard
> > > > > +      * (non HW wrapped) keys.
> > > >
> > > > I can't say this is very logical.
> > > >
> > > > standard mode => HW wrapped keys
> > > > legacy mode => standard keys
> > > >
> > > > Consider changing the terms.
> > > >
> > >
> > > Ack, will make this clearer
> > >
> > > > > +      *
> > > > > +      * Put ICE in standard mode, ICE defaults to legacy mode.
> > > > > +      * Legacy mode - ICE HWKM slave not supported.
> > > > > +      * Standard mode - ICE HWKM slave supported.
> > > >
> > > > s/slave/some other term/
> > > >
> > > Ack - will address this.
> > >
> > > > Is it possible to use both kind of keys when working on standard mode?
> > > > If not, it should be the user who selects what type of keys to be used.
> > > > Enforcing this via DT is not a way to go.
> > > >
> > >
> > > Unfortunately, that support is not there yet. When you say user, do
> > > you mean to have it as a filesystem mount option?
> >
> > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > to be able to use either a hardware-wrapped key or a standard key.
> >
>
> What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)

I must admit, I mostly used dm-crypt beforehand, so I had to look at
fscrypt now. Some of my previous comments might not be fully
applicable.

> Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> And specify policies (links to keys) for different folders.
>
> > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > information is needed when the modules are loaded.
> > >
> > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> >
> > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > keys. But the line doesn't specify that standard keys are not supported.
> >
>
> Those are capabilities that are read from the storage controller. However, wrapped keys
> Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> from the SoC.
>
> QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> That is something we are internally working on, but not available yet.

I'd say this is a significant obstacle, at least from my point of
view. I understand that the default might be to use hw-wrapped keys,
but it should be possible for the user to select non-HW keys if the
ability to recover the data is considered to be important. Note, I'm
really pointing to the user here, not to the system integrator. So
using DT property or specifying kernel arguments to switch between
these modes is not really an option.

But I'd really love to hear some feedback from linux-security and/or
linux-fscrypt here.

In my humble opinion the user should be able to specify that the key
is wrapped using the hardware KMK. Then if the hardware has already
started using the other kind of keys, it should be able to respond
with -EINVAL / whatever else. Then the user can evict previously
programmed key and program a desired one.

> > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > out why that's not the case?
> >
>
> I will evaluate this.
> But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> driver. The interface is through QCOM SCM driver.

Note, this is just an API interface, see how it is implemented for the
CAAM hardware.

>
> > > I am thinking of a way now to do this with DT, but without having a new
> > vendor property.
> > > Is it acceptable to use the addressable range as the deciding factor?
> > > Say use legacy mode of ICE when the addressable size is 0x8000 and use
> > > HWKM mode of ICE when the addressable size is 0x10000.
> >
> > Definitely, this is a NAK. It's a very unobvious hack. You have been asked to
> > use compatible strings to detect whether HW keys are supported or not.

-- 
With best wishes
Dmitry

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Eric Biggers]

On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > >
> > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > Enforcing this via DT is not a way to go.
> > > > >
> > > >
> > > > Unfortunately, that support is not there yet. When you say user, do
> > > > you mean to have it as a filesystem mount option?
> > >
> > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > to be able to use either a hardware-wrapped key or a standard key.
> > >
> >
> > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> 
> I must admit, I mostly used dm-crypt beforehand, so I had to look at
> fscrypt now. Some of my previous comments might not be fully
> applicable.
> 
> > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > And specify policies (links to keys) for different folders.
> >
> > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > information is needed when the modules are loaded.
> > > >
> > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > >
> > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > keys. But the line doesn't specify that standard keys are not supported.
> > >
> >
> > Those are capabilities that are read from the storage controller. However, wrapped keys
> > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > from the SoC.
> >
> > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > That is something we are internally working on, but not available yet.
> 
> I'd say this is a significant obstacle, at least from my point of
> view. I understand that the default might be to use hw-wrapped keys,
> but it should be possible for the user to select non-HW keys if the
> ability to recover the data is considered to be important. Note, I'm
> really pointing to the user here, not to the system integrator. So
> using DT property or specifying kernel arguments to switch between
> these modes is not really an option.
> 
> But I'd really love to hear some feedback from linux-security and/or
> linux-fscrypt here.
> 
> In my humble opinion the user should be able to specify that the key
> is wrapped using the hardware KMK. Then if the hardware has already
> started using the other kind of keys, it should be able to respond
> with -EINVAL / whatever else. Then the user can evict previously
> programmed key and program a desired one.
> 
> > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > out why that's not the case?
> > >
> >
> > I will evaluate this.
> > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > driver. The interface is through QCOM SCM driver.
> 
> Note, this is just an API interface, see how it is implemented for the
> CAAM hardware.
> 

The problem is that this patchset was sent out without the patches that add the
block and filesystem-level framework for hardware-wrapped inline encryption
keys, which it depends on.  So it's lacking context.  The proposed framework can
be found at
https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u

As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
keys" are based around a model where the kernel can request that keys be sealed
and unsealed using a trust source, and the kernel gets access to the raw
unsealed keys.  Hardware-wrapped inline encryption keys use a different model
where the kernel never gets access to the raw keys.  They also have the concept
of ephemeral wrapping which does not exist in "trusted keys".  And they need to
be properly integrated with the inline encryption framework in the block layer.

- Eric

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Fri, 21 Jun 2024 at 07:47, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > >
> > > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > > Enforcing this via DT is not a way to go.
> > > > > >
> > > > >
> > > > > Unfortunately, that support is not there yet. When you say user, do
> > > > > you mean to have it as a filesystem mount option?
> > > >
> > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > > to be able to use either a hardware-wrapped key or a standard key.
> > > >
> > >
> > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> >
> > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > fscrypt now. Some of my previous comments might not be fully
> > applicable.
> >
> > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > > And specify policies (links to keys) for different folders.
> > >
> > > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > > information is needed when the modules are loaded.
> > > > >
> > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > >
> > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > > keys. But the line doesn't specify that standard keys are not supported.
> > > >
> > >
> > > Those are capabilities that are read from the storage controller. However, wrapped keys
> > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > > from the SoC.
> > >
> > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > > That is something we are internally working on, but not available yet.
> >
> > I'd say this is a significant obstacle, at least from my point of
> > view. I understand that the default might be to use hw-wrapped keys,
> > but it should be possible for the user to select non-HW keys if the
> > ability to recover the data is considered to be important. Note, I'm
> > really pointing to the user here, not to the system integrator. So
> > using DT property or specifying kernel arguments to switch between
> > these modes is not really an option.
> >
> > But I'd really love to hear some feedback from linux-security and/or
> > linux-fscrypt here.
> >
> > In my humble opinion the user should be able to specify that the key
> > is wrapped using the hardware KMK. Then if the hardware has already
> > started using the other kind of keys, it should be able to respond
> > with -EINVAL / whatever else. Then the user can evict previously
> > programmed key and program a desired one.
> >
> > > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > > out why that's not the case?
> > > >
> > >
> > > I will evaluate this.
> > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > > driver. The interface is through QCOM SCM driver.
> >
> > Note, this is just an API interface, see how it is implemented for the
> > CAAM hardware.
> >
>
> The problem is that this patchset was sent out without the patches that add the
> block and filesystem-level framework for hardware-wrapped inline encryption
> keys, which it depends on.  So it's lacking context.  The proposed framework can
> be found at
> https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u

Thank you. I have quickly skimmed through the patches, but I didn't
review them thoroughly. Maybe the patchset already implements the
interfaces that I'm thinking about. In such a case please excuse me. I
will give it a more thorough look later today.

> As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> keys" are based around a model where the kernel can request that keys be sealed
> and unsealed using a trust source, and the kernel gets access to the raw
> unsealed keys.  Hardware-wrapped inline encryption keys use a different model
> where the kernel never gets access to the raw keys.  They also have the concept
> of ephemeral wrapping which does not exist in "trusted keys".  And they need to
> be properly integrated with the inline encryption framework in the block layer.

Then what exactly does qcom_scm_derive_sw_secret() do? Does it rewrap
the key under some other key?
I had the feeling that there are two separate pieces of functionality
being stuffed into a single patchset and into a single solution.

First one is handling the keys. I keep on thinking that there should
be a separate software interface to unseal the key and rewrap it under
an ephemeral key. Some hardware might permit importing raw keys. Other
hardware might insist on generating the keys on-chip so that raw keys
can never be used. Anyway, the net result is the binary blob + cookie
for the ephemeral key.

Second part is the actual block interface. Gaurav wrote about
targeting fscrypt, but there should be no actual difference between
crypto targets. FDE or having a single partition encrypted should
probably work in the same way. Convert the key into blk_crypto_key
(including the cookie for the ephemeral key), program the key into the
slot, use the slot to en/decrypt hardware blocks.

My main point is that the decision on the key type should be coming
from the user. I can easily imagine a user, which wants to use
password / raw key for documents storage so that it is possible to
recover the data, hw-wrapped long-term key for app & data storage and
generated one-time random key for the swap, so that memory contents
can never be recovered after reboot / device capture.

-- 
With best wishes
Dmitry

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap]

Hello Eric

On 06/20/2024, 9:48 PM PDT, Eric Biggers wrote:
> On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > >
> > > > > > Is it possible to use both kind of keys when working on standard
> mode?
> > > > > > If not, it should be the user who selects what type of keys to be
> used.
> > > > > > Enforcing this via DT is not a way to go.
> > > > > >
> > > > >
> > > > > Unfortunately, that support is not there yet. When you say user,
> > > > > do you mean to have it as a filesystem mount option?
> > > >
> > > > During cryptsetup time. When running e.g. cryptsetup I, as a user,
> > > > would like to be able to use either a hardware-wrapped key or a
> standard key.
> > > >
> > >
> > > What we are looking for with these patches is for per-file/folder
> encryption using fscrypt policies.
> > > Cryptsetup to my understanding supports only full-disk , and does
> > > not support FBE (File-Based)
> >
> > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > fscrypt now. Some of my previous comments might not be fully
> > applicable.
> >
> > > Hence the idea here is that we mount an unencrypted device (with the
> > > inlinecrypt option that indicates inline encryption is supported) And
> specify policies (links to keys) for different folders.
> > >
> > > > > The way the UFS/EMMC crypto layer is designed currently is that,
> > > > > this information is needed when the modules are loaded.
> > > > >
> > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kern
> > > > > el.org /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > >
> > > > I see that the driver lists capabilities here. E.g. that it
> > > > supports HW-wrapped keys. But the line doesn't specify that standard
> keys are not supported.
> > > >
> > >
> > > Those are capabilities that are read from the storage controller.
> > > However, wrapped keys Are not a standard in the ICE JEDEC
> > > specification, and in most cases, is a value add coming from the SoC.
> > >
> > > QCOM SOC and firmware currently does not support both kinds of keys in
> the HWKM mode.
> > > That is something we are internally working on, but not available yet.
> >
> > I'd say this is a significant obstacle, at least from my point of
> > view. I understand that the default might be to use hw-wrapped keys,
> > but it should be possible for the user to select non-HW keys if the
> > ability to recover the data is considered to be important. Note, I'm
> > really pointing to the user here, not to the system integrator. So
> > using DT property or specifying kernel arguments to switch between
> > these modes is not really an option.
> >
> > But I'd really love to hear some feedback from linux-security and/or
> > linux-fscrypt here.
> >
> > In my humble opinion the user should be able to specify that the key
> > is wrapped using the hardware KMK. Then if the hardware has already
> > started using the other kind of keys, it should be able to respond
> > with -EINVAL / whatever else. Then the user can evict previously
> > programmed key and program a desired one.
> >
> > > > Also, I'd have expected that hw-wrapped keys are handled using
> > > > trusted keys mechanism (see security/keys/trusted-keys/). Could
> > > > you please point out why that's not the case?
> > > >
> > >
> > > I will evaluate this.
> > > But my initial response is that we currently cannot communicate to
> > > our TPM directly from HLOS, but goes through QTEE, and I don't think
> > > our qtee currently interfaces with the open source tee driver. The
> interface is through QCOM SCM driver.
> >
> > Note, this is just an API interface, see how it is implemented for the
> > CAAM hardware.
> >
> 
> The problem is that this patchset was sent out without the patches that add
> the block and filesystem-level framework for hardware-wrapped inline
> encryption keys, which it depends on.  So it's lacking context.  The proposed
> framework can be found at https://lore.kernel.org/linux-
> block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> 

I have only been adding the fscryp patch link as part of the cover letter - as a dependency.
https://lore.kernel.org/all/20240617005825.1443206-1-quic_gaurkash@quicinc.com/
If you would like me to include it in the patch series itself, I can do that as well.

> As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> keys" are based around a model where the kernel can request that keys be
> sealed and unsealed using a trust source, and the kernel gets access to the
> raw unsealed keys.  Hardware-wrapped inline encryption keys use a
> different model where the kernel never gets access to the raw keys.  They
> also have the concept of ephemeral wrapping which does not exist in
> "trusted keys".  And they need to be properly integrated with the inline
> encryption framework in the block layer.
> 
> - Eric

Regards,
Gaurav

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap (QUIC)]

Apologies, fixed incorrect email

> Hello Eric
> 
> On 06/20/2024, 9:48 PM PDT, Eric Biggers wrote:
> > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > >
> > > > > > > Is it possible to use both kind of keys when working on
> > > > > > > standard
> > mode?
> > > > > > > If not, it should be the user who selects what type of keys
> > > > > > > to be
> > used.
> > > > > > > Enforcing this via DT is not a way to go.
> > > > > > >
> > > > > >
> > > > > > Unfortunately, that support is not there yet. When you say
> > > > > > user, do you mean to have it as a filesystem mount option?
> > > > >
> > > > > During cryptsetup time. When running e.g. cryptsetup I, as a
> > > > > user, would like to be able to use either a hardware-wrapped key
> > > > > or a
> > standard key.
> > > > >
> > > >
> > > > What we are looking for with these patches is for per-file/folder
> > encryption using fscrypt policies.
> > > > Cryptsetup to my understanding supports only full-disk , and does
> > > > not support FBE (File-Based)
> > >
> > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > fscrypt now. Some of my previous comments might not be fully
> > > applicable.
> > >
> > > > Hence the idea here is that we mount an unencrypted device (with
> > > > the inlinecrypt option that indicates inline encryption is
> > > > supported) And
> > specify policies (links to keys) for different folders.
> > > >
> > > > > > The way the UFS/EMMC crypto layer is designed currently is
> > > > > > that, this information is needed when the modules are loaded.
> > > > > >
> > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@ke
> > > > > > rn el.org /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > >
> > > > > I see that the driver lists capabilities here. E.g. that it
> > > > > supports HW-wrapped keys. But the line doesn't specify that
> > > > > standard
> > keys are not supported.
> > > > >
> > > >
> > > > Those are capabilities that are read from the storage controller.
> > > > However, wrapped keys Are not a standard in the ICE JEDEC
> > > > specification, and in most cases, is a value add coming from the SoC.
> > > >
> > > > QCOM SOC and firmware currently does not support both kinds of
> > > > keys in
> > the HWKM mode.
> > > > That is something we are internally working on, but not available yet.
> > >
> > > I'd say this is a significant obstacle, at least from my point of
> > > view. I understand that the default might be to use hw-wrapped keys,
> > > but it should be possible for the user to select non-HW keys if the
> > > ability to recover the data is considered to be important. Note, I'm
> > > really pointing to the user here, not to the system integrator. So
> > > using DT property or specifying kernel arguments to switch between
> > > these modes is not really an option.
> > >
> > > But I'd really love to hear some feedback from linux-security and/or
> > > linux-fscrypt here.
> > >
> > > In my humble opinion the user should be able to specify that the key
> > > is wrapped using the hardware KMK. Then if the hardware has already
> > > started using the other kind of keys, it should be able to respond
> > > with -EINVAL / whatever else. Then the user can evict previously
> > > programmed key and program a desired one.
> > >
> > > > > Also, I'd have expected that hw-wrapped keys are handled using
> > > > > trusted keys mechanism (see security/keys/trusted-keys/). Could
> > > > > you please point out why that's not the case?
> > > > >
> > > >
> > > > I will evaluate this.
> > > > But my initial response is that we currently cannot communicate to
> > > > our TPM directly from HLOS, but goes through QTEE, and I don't
> > > > think our qtee currently interfaces with the open source tee
> > > > driver. The
> > interface is through QCOM SCM driver.
> > >
> > > Note, this is just an API interface, see how it is implemented for
> > > the CAAM hardware.
> > >
> >
> > The problem is that this patchset was sent out without the patches
> > that add the block and filesystem-level framework for hardware-wrapped
> > inline encryption keys, which it depends on.  So it's lacking context.
> > The proposed framework can be found at https://lore.kernel.org/linux-
> > block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> >
> 
> I have only been adding the fscryp patch link as part of the cover letter - as a
> dependency.
> https://lore.kernel.org/all/20240617005825.1443206-1-
> quic_gaurkash@quicinc.com/
> If you would like me to include it in the patch series itself, I can do that as
> well.
> 
> > As for why "trusted keys" aren't used, they just aren't helpful here.
> > "Trusted keys" are based around a model where the kernel can request
> > that keys be sealed and unsealed using a trust source, and the kernel
> > gets access to the raw unsealed keys.  Hardware-wrapped inline
> > encryption keys use a different model where the kernel never gets
> > access to the raw keys.  They also have the concept of ephemeral
> > wrapping which does not exist in "trusted keys".  And they need to be
> > properly integrated with the inline encryption framework in the block layer.
> >
> > - Eric
> 
> Regards,
> Gaurav

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Eric Biggers]

On Fri, Jun 21, 2024 at 06:16:37PM +0300, Dmitry Baryshkov wrote:
> On Fri, 21 Jun 2024 at 07:47, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > >
> > > > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > > > Enforcing this via DT is not a way to go.
> > > > > > >
> > > > > >
> > > > > > Unfortunately, that support is not there yet. When you say user, do
> > > > > > you mean to have it as a filesystem mount option?
> > > > >
> > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > > > to be able to use either a hardware-wrapped key or a standard key.
> > > > >
> > > >
> > > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> > >
> > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > fscrypt now. Some of my previous comments might not be fully
> > > applicable.
> > >
> > > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > > > And specify policies (links to keys) for different folders.
> > > >
> > > > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > > > information is needed when the modules are loaded.
> > > > > >
> > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > >
> > > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > > > keys. But the line doesn't specify that standard keys are not supported.
> > > > >
> > > >
> > > > Those are capabilities that are read from the storage controller. However, wrapped keys
> > > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > > > from the SoC.
> > > >
> > > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > > > That is something we are internally working on, but not available yet.
> > >
> > > I'd say this is a significant obstacle, at least from my point of
> > > view. I understand that the default might be to use hw-wrapped keys,
> > > but it should be possible for the user to select non-HW keys if the
> > > ability to recover the data is considered to be important. Note, I'm
> > > really pointing to the user here, not to the system integrator. So
> > > using DT property or specifying kernel arguments to switch between
> > > these modes is not really an option.
> > >
> > > But I'd really love to hear some feedback from linux-security and/or
> > > linux-fscrypt here.
> > >
> > > In my humble opinion the user should be able to specify that the key
> > > is wrapped using the hardware KMK. Then if the hardware has already
> > > started using the other kind of keys, it should be able to respond
> > > with -EINVAL / whatever else. Then the user can evict previously
> > > programmed key and program a desired one.
> > >
> > > > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > > > out why that's not the case?
> > > > >
> > > >
> > > > I will evaluate this.
> > > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > > > driver. The interface is through QCOM SCM driver.
> > >
> > > Note, this is just an API interface, see how it is implemented for the
> > > CAAM hardware.
> > >
> >
> > The problem is that this patchset was sent out without the patches that add the
> > block and filesystem-level framework for hardware-wrapped inline encryption
> > keys, which it depends on.  So it's lacking context.  The proposed framework can
> > be found at
> > https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> 
> Thank you. I have quickly skimmed through the patches, but I didn't
> review them thoroughly. Maybe the patchset already implements the
> interfaces that I'm thinking about. In such a case please excuse me. I
> will give it a more thorough look later today.
> 
> > As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> > keys" are based around a model where the kernel can request that keys be sealed
> > and unsealed using a trust source, and the kernel gets access to the raw
> > unsealed keys.  Hardware-wrapped inline encryption keys use a different model
> > where the kernel never gets access to the raw keys.  They also have the concept
> > of ephemeral wrapping which does not exist in "trusted keys".  And they need to
> > be properly integrated with the inline encryption framework in the block layer.
> 
> Then what exactly does qcom_scm_derive_sw_secret() do? Does it rewrap
> the key under some other key?

It derives a secret for functionality such as filenames encryption that can't
use inline encryption.

> I had the feeling that there are two separate pieces of functionality
> being stuffed into a single patchset and into a single solution.
> 
> First one is handling the keys. I keep on thinking that there should
> be a separate software interface to unseal the key and rewrap it under
> an ephemeral key.

There is.  That's what the BLKCRYPTOPREPAREKEY ioctl is for.

> Some hardware might permit importing raw keys.

That's what BLKCRYPTOIMPORTKEY is for.

> Other hardware might insist on generating the keys on-chip so that raw keys
> can never be used.

And that's what BLKCRYPTOGENERATEKEY is for.

> Second part is the actual block interface. Gaurav wrote about
> targeting fscrypt, but there should be no actual difference between
> crypto targets. FDE or having a single partition encrypted should
> probably work in the same way. Convert the key into blk_crypto_key
> (including the cookie for the ephemeral key), program the key into the
> slot, use the slot to en/decrypt hardware blocks.
> 
> My main point is that the decision on the key type should be coming
> from the user.

That's exactly how it works.  There is a block interface for specifying an
inline encryption key along with each bio.  The submitter of the bio can specify
either a standard key or a HW-wrapped key.

Again, take a look at the patchset
https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u.
That's where all this stuff is.

Thanks,

- Eric

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Eric Biggers]

On Fri, Jun 21, 2024 at 03:35:40PM +0000, Gaurav Kashyap wrote:
> Hello Eric
> 
> On 06/20/2024, 9:48 PM PDT, Eric Biggers wrote:
> > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > >
> > > > > > > Is it possible to use both kind of keys when working on standard
> > mode?
> > > > > > > If not, it should be the user who selects what type of keys to be
> > used.
> > > > > > > Enforcing this via DT is not a way to go.
> > > > > > >
> > > > > >
> > > > > > Unfortunately, that support is not there yet. When you say user,
> > > > > > do you mean to have it as a filesystem mount option?
> > > > >
> > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user,
> > > > > would like to be able to use either a hardware-wrapped key or a
> > standard key.
> > > > >
> > > >
> > > > What we are looking for with these patches is for per-file/folder
> > encryption using fscrypt policies.
> > > > Cryptsetup to my understanding supports only full-disk , and does
> > > > not support FBE (File-Based)
> > >
> > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > fscrypt now. Some of my previous comments might not be fully
> > > applicable.
> > >
> > > > Hence the idea here is that we mount an unencrypted device (with the
> > > > inlinecrypt option that indicates inline encryption is supported) And
> > specify policies (links to keys) for different folders.
> > > >
> > > > > > The way the UFS/EMMC crypto layer is designed currently is that,
> > > > > > this information is needed when the modules are loaded.
> > > > > >
> > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kern
> > > > > > el.org /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > >
> > > > > I see that the driver lists capabilities here. E.g. that it
> > > > > supports HW-wrapped keys. But the line doesn't specify that standard
> > keys are not supported.
> > > > >
> > > >
> > > > Those are capabilities that are read from the storage controller.
> > > > However, wrapped keys Are not a standard in the ICE JEDEC
> > > > specification, and in most cases, is a value add coming from the SoC.
> > > >
> > > > QCOM SOC and firmware currently does not support both kinds of keys in
> > the HWKM mode.
> > > > That is something we are internally working on, but not available yet.
> > >
> > > I'd say this is a significant obstacle, at least from my point of
> > > view. I understand that the default might be to use hw-wrapped keys,
> > > but it should be possible for the user to select non-HW keys if the
> > > ability to recover the data is considered to be important. Note, I'm
> > > really pointing to the user here, not to the system integrator. So
> > > using DT property or specifying kernel arguments to switch between
> > > these modes is not really an option.
> > >
> > > But I'd really love to hear some feedback from linux-security and/or
> > > linux-fscrypt here.
> > >
> > > In my humble opinion the user should be able to specify that the key
> > > is wrapped using the hardware KMK. Then if the hardware has already
> > > started using the other kind of keys, it should be able to respond
> > > with -EINVAL / whatever else. Then the user can evict previously
> > > programmed key and program a desired one.
> > >
> > > > > Also, I'd have expected that hw-wrapped keys are handled using
> > > > > trusted keys mechanism (see security/keys/trusted-keys/). Could
> > > > > you please point out why that's not the case?
> > > > >
> > > >
> > > > I will evaluate this.
> > > > But my initial response is that we currently cannot communicate to
> > > > our TPM directly from HLOS, but goes through QTEE, and I don't think
> > > > our qtee currently interfaces with the open source tee driver. The
> > interface is through QCOM SCM driver.
> > >
> > > Note, this is just an API interface, see how it is implemented for the
> > > CAAM hardware.
> > >
> > 
> > The problem is that this patchset was sent out without the patches that add
> > the block and filesystem-level framework for hardware-wrapped inline
> > encryption keys, which it depends on.  So it's lacking context.  The proposed
> > framework can be found at https://lore.kernel.org/linux-
> > block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> > 
> 
> I have only been adding the fscryp patch link as part of the cover letter - as a dependency.
> https://lore.kernel.org/all/20240617005825.1443206-1-quic_gaurkash@quicinc.com/
> If you would like me to include it in the patch series itself, I can do that as well.
> 

I think including all prerequisite patches would be helpful for reviewers.

Thanks for continuing to work on this!

I still need to get ahold of a sm8650 based device and test this out.  Is the
SM8650 HDK the only option, or is there a sm8650 based phone with upstream
support yet?

- Eric

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Fri, 21 Jun 2024 at 18:39, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Fri, Jun 21, 2024 at 06:16:37PM +0300, Dmitry Baryshkov wrote:
> > On Fri, 21 Jun 2024 at 07:47, Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > > >
> > > > > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > > > > Enforcing this via DT is not a way to go.
> > > > > > > >
> > > > > > >
> > > > > > > Unfortunately, that support is not there yet. When you say user, do
> > > > > > > you mean to have it as a filesystem mount option?
> > > > > >
> > > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > > > > to be able to use either a hardware-wrapped key or a standard key.
> > > > > >
> > > > >
> > > > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > > > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> > > >
> > > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > > fscrypt now. Some of my previous comments might not be fully
> > > > applicable.
> > > >
> > > > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > > > > And specify policies (links to keys) for different folders.
> > > > >
> > > > > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > > > > information is needed when the modules are loaded.
> > > > > > >
> > > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > > >
> > > > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > > > > keys. But the line doesn't specify that standard keys are not supported.
> > > > > >
> > > > >
> > > > > Those are capabilities that are read from the storage controller. However, wrapped keys
> > > > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > > > > from the SoC.
> > > > >
> > > > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > > > > That is something we are internally working on, but not available yet.
> > > >
> > > > I'd say this is a significant obstacle, at least from my point of
> > > > view. I understand that the default might be to use hw-wrapped keys,
> > > > but it should be possible for the user to select non-HW keys if the
> > > > ability to recover the data is considered to be important. Note, I'm
> > > > really pointing to the user here, not to the system integrator. So
> > > > using DT property or specifying kernel arguments to switch between
> > > > these modes is not really an option.
> > > >
> > > > But I'd really love to hear some feedback from linux-security and/or
> > > > linux-fscrypt here.
> > > >
> > > > In my humble opinion the user should be able to specify that the key
> > > > is wrapped using the hardware KMK. Then if the hardware has already
> > > > started using the other kind of keys, it should be able to respond
> > > > with -EINVAL / whatever else. Then the user can evict previously
> > > > programmed key and program a desired one.
> > > >
> > > > > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > > > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > > > > out why that's not the case?
> > > > > >
> > > > >
> > > > > I will evaluate this.
> > > > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > > > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > > > > driver. The interface is through QCOM SCM driver.
> > > >
> > > > Note, this is just an API interface, see how it is implemented for the
> > > > CAAM hardware.
> > > >
> > >
> > > The problem is that this patchset was sent out without the patches that add the
> > > block and filesystem-level framework for hardware-wrapped inline encryption
> > > keys, which it depends on.  So it's lacking context.  The proposed framework can
> > > be found at
> > > https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> >
> > Thank you. I have quickly skimmed through the patches, but I didn't
> > review them thoroughly. Maybe the patchset already implements the
> > interfaces that I'm thinking about. In such a case please excuse me. I
> > will give it a more thorough look later today.
> >
> > > As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> > > keys" are based around a model where the kernel can request that keys be sealed
> > > and unsealed using a trust source, and the kernel gets access to the raw
> > > unsealed keys.  Hardware-wrapped inline encryption keys use a different model
> > > where the kernel never gets access to the raw keys.  They also have the concept
> > > of ephemeral wrapping which does not exist in "trusted keys".  And they need to
> > > be properly integrated with the inline encryption framework in the block layer.
> >
> > Then what exactly does qcom_scm_derive_sw_secret() do? Does it rewrap
> > the key under some other key?
>
> It derives a secret for functionality such as filenames encryption that can't
> use inline encryption.
>
> > I had the feeling that there are two separate pieces of functionality
> > being stuffed into a single patchset and into a single solution.
> >
> > First one is handling the keys. I keep on thinking that there should
> > be a separate software interface to unseal the key and rewrap it under
> > an ephemeral key.
>
> There is.  That's what the BLKCRYPTOPREPAREKEY ioctl is for.
>
> > Some hardware might permit importing raw keys.
>
> That's what BLKCRYPTOIMPORTKEY is for.
>
> > Other hardware might insist on generating the keys on-chip so that raw keys
> > can never be used.
>
> And that's what BLKCRYPTOGENERATEKEY is for.

Again, this might be answered somewhere, but why can't we use keyctl
for handling the keys and then use a single IOCTL to point the block
device to the key in the keyring?

>
> > Second part is the actual block interface. Gaurav wrote about
> > targeting fscrypt, but there should be no actual difference between
> > crypto targets. FDE or having a single partition encrypted should
> > probably work in the same way. Convert the key into blk_crypto_key
> > (including the cookie for the ephemeral key), program the key into the
> > slot, use the slot to en/decrypt hardware blocks.
> >
> > My main point is that the decision on the key type should be coming
> > from the user.
>
> That's exactly how it works.  There is a block interface for specifying an
> inline encryption key along with each bio.  The submitter of the bio can specify
> either a standard key or a HW-wrapped key.

Not in this patchset. The ICE driver decides whether it can support
HW-wrapped keys or not and then fails to support other type of keys.

>
> Again, take a look at the patchset
> https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u.
> That's where all this stuff is.

I was mostly looking at the hardware-specific implementation.

-- 
With best wishes
Dmitry

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Eric Biggers]

On Fri, Jun 21, 2024 at 07:06:25PM +0300, Dmitry Baryshkov wrote:
> On Fri, 21 Jun 2024 at 18:39, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Fri, Jun 21, 2024 at 06:16:37PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, 21 Jun 2024 at 07:47, Eric Biggers <ebiggers@kernel.org> wrote:
> > > >
> > > > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > > > >
> > > > > > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > > > > > Enforcing this via DT is not a way to go.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Unfortunately, that support is not there yet. When you say user, do
> > > > > > > > you mean to have it as a filesystem mount option?
> > > > > > >
> > > > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > > > > > to be able to use either a hardware-wrapped key or a standard key.
> > > > > > >
> > > > > >
> > > > > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > > > > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> > > > >
> > > > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > > > fscrypt now. Some of my previous comments might not be fully
> > > > > applicable.
> > > > >
> > > > > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > > > > > And specify policies (links to keys) for different folders.
> > > > > >
> > > > > > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > > > > > information is needed when the modules are loaded.
> > > > > > > >
> > > > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > > > >
> > > > > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > > > > > keys. But the line doesn't specify that standard keys are not supported.
> > > > > > >
> > > > > >
> > > > > > Those are capabilities that are read from the storage controller. However, wrapped keys
> > > > > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > > > > > from the SoC.
> > > > > >
> > > > > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > > > > > That is something we are internally working on, but not available yet.
> > > > >
> > > > > I'd say this is a significant obstacle, at least from my point of
> > > > > view. I understand that the default might be to use hw-wrapped keys,
> > > > > but it should be possible for the user to select non-HW keys if the
> > > > > ability to recover the data is considered to be important. Note, I'm
> > > > > really pointing to the user here, not to the system integrator. So
> > > > > using DT property or specifying kernel arguments to switch between
> > > > > these modes is not really an option.
> > > > >
> > > > > But I'd really love to hear some feedback from linux-security and/or
> > > > > linux-fscrypt here.
> > > > >
> > > > > In my humble opinion the user should be able to specify that the key
> > > > > is wrapped using the hardware KMK. Then if the hardware has already
> > > > > started using the other kind of keys, it should be able to respond
> > > > > with -EINVAL / whatever else. Then the user can evict previously
> > > > > programmed key and program a desired one.
> > > > >
> > > > > > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > > > > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > > > > > out why that's not the case?
> > > > > > >
> > > > > >
> > > > > > I will evaluate this.
> > > > > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > > > > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > > > > > driver. The interface is through QCOM SCM driver.
> > > > >
> > > > > Note, this is just an API interface, see how it is implemented for the
> > > > > CAAM hardware.
> > > > >
> > > >
> > > > The problem is that this patchset was sent out without the patches that add the
> > > > block and filesystem-level framework for hardware-wrapped inline encryption
> > > > keys, which it depends on.  So it's lacking context.  The proposed framework can
> > > > be found at
> > > > https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> > >
> > > Thank you. I have quickly skimmed through the patches, but I didn't
> > > review them thoroughly. Maybe the patchset already implements the
> > > interfaces that I'm thinking about. In such a case please excuse me. I
> > > will give it a more thorough look later today.
> > >
> > > > As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> > > > keys" are based around a model where the kernel can request that keys be sealed
> > > > and unsealed using a trust source, and the kernel gets access to the raw
> > > > unsealed keys.  Hardware-wrapped inline encryption keys use a different model
> > > > where the kernel never gets access to the raw keys.  They also have the concept
> > > > of ephemeral wrapping which does not exist in "trusted keys".  And they need to
> > > > be properly integrated with the inline encryption framework in the block layer.
> > >
> > > Then what exactly does qcom_scm_derive_sw_secret() do? Does it rewrap
> > > the key under some other key?
> >
> > It derives a secret for functionality such as filenames encryption that can't
> > use inline encryption.
> >
> > > I had the feeling that there are two separate pieces of functionality
> > > being stuffed into a single patchset and into a single solution.
> > >
> > > First one is handling the keys. I keep on thinking that there should
> > > be a separate software interface to unseal the key and rewrap it under
> > > an ephemeral key.
> >
> > There is.  That's what the BLKCRYPTOPREPAREKEY ioctl is for.
> >
> > > Some hardware might permit importing raw keys.
> >
> > That's what BLKCRYPTOIMPORTKEY is for.
> >
> > > Other hardware might insist on generating the keys on-chip so that raw keys
> > > can never be used.
> >
> > And that's what BLKCRYPTOGENERATEKEY is for.
> 
> Again, this might be answered somewhere, but why can't we use keyctl
> for handling the keys and then use a single IOCTL to point the block
> device to the key in the keyring?

All the same functionality would need to be supported, and I think that
shoehorning it into the keyrings service instead of just adding new ioctls would
be more difficult.  The keyrings service was not designed for this use case.
We've already had a lot of problems trying to take advantage of the keyrings
service in fscrypt previously.  The keyrings service is something that sounds
useful but really isn't all that useful.

By "a single IOCTL to point the block device to the key in the keyring", you
seem to be referring to configuring full block device encryption with a single
key.  That's not something that's supported by the upstream kernel yet, and it's
not related to this patchset; currently only fscrypt supports inline encryption.
Support for it will be added at some point, which will likely indeed take the
form of an ioctl to set a key on a block device.  But that would be the case
even without HW-wrapped keys.  And *requiring* the key to be given in a keyring
(instead of just in a byte array passed to the ioctl) isn't very helpful, as it
just makes the API harder to use.  We've learned this from the fscrypt API
already where we actually had to move away from the keyrings service in order to
fix all the issues caused by it (see FS_IOC_ADD_ENCRYPTION_KEY).

> >
> > > Second part is the actual block interface. Gaurav wrote about
> > > targeting fscrypt, but there should be no actual difference between
> > > crypto targets. FDE or having a single partition encrypted should
> > > probably work in the same way. Convert the key into blk_crypto_key
> > > (including the cookie for the ephemeral key), program the key into the
> > > slot, use the slot to en/decrypt hardware blocks.
> > >
> > > My main point is that the decision on the key type should be coming
> > > from the user.
> >
> > That's exactly how it works.  There is a block interface for specifying an
> > inline encryption key along with each bio.  The submitter of the bio can specify
> > either a standard key or a HW-wrapped key.
> 
> Not in this patchset. The ICE driver decides whether it can support
> HW-wrapped keys or not and then fails to support other type of keys.
> 

Sure, that's just a matter of hardware capabilities though, right?  The block
layer provides a way for drivers to declare which inline encryption capabilities
they support.  They can declare they support standard keys, HW-wrapped keys,
both, or neither.  If Qualcomm SoCs can't support both types of keys at the same
time, that's unfortunate, but I'm not sure what your point is.  The user (e.g.
fscrypt) still has control over whether they use the functionality that the
hardware provides.

- Eric

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Fri, 21 Jun 2024 at 19:31, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Fri, Jun 21, 2024 at 07:06:25PM +0300, Dmitry Baryshkov wrote:
> > On Fri, 21 Jun 2024 at 18:39, Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > On Fri, Jun 21, 2024 at 06:16:37PM +0300, Dmitry Baryshkov wrote:
> > > > On Fri, 21 Jun 2024 at 07:47, Eric Biggers <ebiggers@kernel.org> wrote:
> > > > >
> > > > > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > > > > >
> > > > > > > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > > > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > > > > > > Enforcing this via DT is not a way to go.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Unfortunately, that support is not there yet. When you say user, do
> > > > > > > > > you mean to have it as a filesystem mount option?
> > > > > > > >
> > > > > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > > > > > > to be able to use either a hardware-wrapped key or a standard key.
> > > > > > > >
> > > > > > >
> > > > > > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > > > > > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> > > > > >
> > > > > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > > > > fscrypt now. Some of my previous comments might not be fully
> > > > > > applicable.
> > > > > >
> > > > > > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > > > > > > And specify policies (links to keys) for different folders.
> > > > > > >
> > > > > > > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > > > > > > information is needed when the modules are loaded.
> > > > > > > > >
> > > > > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > > > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > > > > >
> > > > > > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > > > > > > keys. But the line doesn't specify that standard keys are not supported.
> > > > > > > >
> > > > > > >
> > > > > > > Those are capabilities that are read from the storage controller. However, wrapped keys
> > > > > > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > > > > > > from the SoC.
> > > > > > >
> > > > > > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > > > > > > That is something we are internally working on, but not available yet.
> > > > > >
> > > > > > I'd say this is a significant obstacle, at least from my point of
> > > > > > view. I understand that the default might be to use hw-wrapped keys,
> > > > > > but it should be possible for the user to select non-HW keys if the
> > > > > > ability to recover the data is considered to be important. Note, I'm
> > > > > > really pointing to the user here, not to the system integrator. So
> > > > > > using DT property or specifying kernel arguments to switch between
> > > > > > these modes is not really an option.
> > > > > >
> > > > > > But I'd really love to hear some feedback from linux-security and/or
> > > > > > linux-fscrypt here.
> > > > > >
> > > > > > In my humble opinion the user should be able to specify that the key
> > > > > > is wrapped using the hardware KMK. Then if the hardware has already
> > > > > > started using the other kind of keys, it should be able to respond
> > > > > > with -EINVAL / whatever else. Then the user can evict previously
> > > > > > programmed key and program a desired one.
> > > > > >
> > > > > > > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > > > > > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > > > > > > out why that's not the case?
> > > > > > > >
> > > > > > >
> > > > > > > I will evaluate this.
> > > > > > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > > > > > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > > > > > > driver. The interface is through QCOM SCM driver.
> > > > > >
> > > > > > Note, this is just an API interface, see how it is implemented for the
> > > > > > CAAM hardware.
> > > > > >
> > > > >
> > > > > The problem is that this patchset was sent out without the patches that add the
> > > > > block and filesystem-level framework for hardware-wrapped inline encryption
> > > > > keys, which it depends on.  So it's lacking context.  The proposed framework can
> > > > > be found at
> > > > > https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> > > >
> > > > Thank you. I have quickly skimmed through the patches, but I didn't
> > > > review them thoroughly. Maybe the patchset already implements the
> > > > interfaces that I'm thinking about. In such a case please excuse me. I
> > > > will give it a more thorough look later today.
> > > >
> > > > > As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> > > > > keys" are based around a model where the kernel can request that keys be sealed
> > > > > and unsealed using a trust source, and the kernel gets access to the raw
> > > > > unsealed keys.  Hardware-wrapped inline encryption keys use a different model
> > > > > where the kernel never gets access to the raw keys.  They also have the concept
> > > > > of ephemeral wrapping which does not exist in "trusted keys".  And they need to
> > > > > be properly integrated with the inline encryption framework in the block layer.
> > > >
> > > > Then what exactly does qcom_scm_derive_sw_secret() do? Does it rewrap
> > > > the key under some other key?
> > >
> > > It derives a secret for functionality such as filenames encryption that can't
> > > use inline encryption.
> > >
> > > > I had the feeling that there are two separate pieces of functionality
> > > > being stuffed into a single patchset and into a single solution.
> > > >
> > > > First one is handling the keys. I keep on thinking that there should
> > > > be a separate software interface to unseal the key and rewrap it under
> > > > an ephemeral key.
> > >
> > > There is.  That's what the BLKCRYPTOPREPAREKEY ioctl is for.
> > >
> > > > Some hardware might permit importing raw keys.
> > >
> > > That's what BLKCRYPTOIMPORTKEY is for.
> > >
> > > > Other hardware might insist on generating the keys on-chip so that raw keys
> > > > can never be used.
> > >
> > > And that's what BLKCRYPTOGENERATEKEY is for.
> >
> > Again, this might be answered somewhere, but why can't we use keyctl
> > for handling the keys and then use a single IOCTL to point the block
> > device to the key in the keyring?
>
> All the same functionality would need to be supported, and I think that
> shoehorning it into the keyrings service instead of just adding new ioctls would
> be more difficult.  The keyrings service was not designed for this use case.
> We've already had a lot of problems trying to take advantage of the keyrings
> service in fscrypt previously.  The keyrings service is something that sounds
> useful but really isn't all that useful.

I would be really interested in reading or listening to any kind of
summary or parts of the issues.
I'm slightly pushy towards keyctl / keyrings, because it already
provides support for different kinds of key wrapping and key
management. Encrypted keys, trusted keys - those are all kinds of key
management, which either will be missing or will have to be
reimplemented for block layers.

I know that keyrings are clumsy and not that logical, but then their
API needs to be improved. Just ignoring the existing mechanisms sounds
like a bad idea.

>
> By "a single IOCTL to point the block device to the key in the keyring", you
> seem to be referring to configuring full block device encryption with a single
> key.  That's not something that's supported by the upstream kernel yet, and it's
> not related to this patchset; currently only fscrypt supports inline encryption.

I see that dm has at least some provisioning and hooks for
CONFIG_BLK_INLINE_ENCRYPTION. Thus I thought that it's possible to use
inline encryption through DM.

> Support for it will be added at some point, which will likely indeed take the
> form of an ioctl to set a key on a block device.  But that would be the case
> even without HW-wrapped keys.  And *requiring* the key to be given in a keyring
> (instead of just in a byte array passed to the ioctl) isn't very helpful, as it
> just makes the API harder to use.  We've learned this from the fscrypt API
> already where we actually had to move away from the keyrings service in order to
> fix all the issues caused by it (see FS_IOC_ADD_ENCRYPTION_KEY).
>
> > >
> > > > Second part is the actual block interface. Gaurav wrote about
> > > > targeting fscrypt, but there should be no actual difference between
> > > > crypto targets. FDE or having a single partition encrypted should
> > > > probably work in the same way. Convert the key into blk_crypto_key
> > > > (including the cookie for the ephemeral key), program the key into the
> > > > slot, use the slot to en/decrypt hardware blocks.
> > > >
> > > > My main point is that the decision on the key type should be coming
> > > > from the user.
> > >
> > > That's exactly how it works.  There is a block interface for specifying an
> > > inline encryption key along with each bio.  The submitter of the bio can specify
> > > either a standard key or a HW-wrapped key.
> >
> > Not in this patchset. The ICE driver decides whether it can support
> > HW-wrapped keys or not and then fails to support other type of keys.
> >
>
> Sure, that's just a matter of hardware capabilities though, right?  The block
> layer provides a way for drivers to declare which inline encryption capabilities
> they support.  They can declare they support standard keys, HW-wrapped keys,
> both, or neither.  If Qualcomm SoCs can't support both types of keys at the same
> time, that's unfortunate, but I'm not sure what your poitnt is.  The user (e.g.
> fscrypt) still has control over whether they use the functionality that the
> hardware provides.

It's a matter of policy. Harware / firmware doesn't support using both
kinds of keys concurrently, if I understood Gaurav's explanations
correctly. But the user should be able to make a judgement and use
non-hw-wrapped keys if it fits their requirements. The driver should
not make this kind of judgement. Note, this is not an issue of your
original patchset, but it's a driver flaw in this patchset.

--
With best wishes
Dmitry

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Eric Biggers]

On Fri, Jun 21, 2024 at 08:49:56PM +0300, Dmitry Baryshkov wrote:
> On Fri, 21 Jun 2024 at 19:31, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Fri, Jun 21, 2024 at 07:06:25PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, 21 Jun 2024 at 18:39, Eric Biggers <ebiggers@kernel.org> wrote:
> > > >
> > > > On Fri, Jun 21, 2024 at 06:16:37PM +0300, Dmitry Baryshkov wrote:
> > > > > On Fri, 21 Jun 2024 at 07:47, Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > >
> > > > > > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > > > > > >
> > > > > > > > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > > > > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > > > > > > > Enforcing this via DT is not a way to go.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Unfortunately, that support is not there yet. When you say user, do
> > > > > > > > > > you mean to have it as a filesystem mount option?
> > > > > > > > >
> > > > > > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > > > > > > > to be able to use either a hardware-wrapped key or a standard key.
> > > > > > > > >
> > > > > > > >
> > > > > > > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > > > > > > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> > > > > > >
> > > > > > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > > > > > fscrypt now. Some of my previous comments might not be fully
> > > > > > > applicable.
> > > > > > >
> > > > > > > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > > > > > > > And specify policies (links to keys) for different folders.
> > > > > > > >
> > > > > > > > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > > > > > > > information is needed when the modules are loaded.
> > > > > > > > > >
> > > > > > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > > > > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > > > > > >
> > > > > > > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > > > > > > > keys. But the line doesn't specify that standard keys are not supported.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Those are capabilities that are read from the storage controller. However, wrapped keys
> > > > > > > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > > > > > > > from the SoC.
> > > > > > > >
> > > > > > > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > > > > > > > That is something we are internally working on, but not available yet.
> > > > > > >
> > > > > > > I'd say this is a significant obstacle, at least from my point of
> > > > > > > view. I understand that the default might be to use hw-wrapped keys,
> > > > > > > but it should be possible for the user to select non-HW keys if the
> > > > > > > ability to recover the data is considered to be important. Note, I'm
> > > > > > > really pointing to the user here, not to the system integrator. So
> > > > > > > using DT property or specifying kernel arguments to switch between
> > > > > > > these modes is not really an option.
> > > > > > >
> > > > > > > But I'd really love to hear some feedback from linux-security and/or
> > > > > > > linux-fscrypt here.
> > > > > > >
> > > > > > > In my humble opinion the user should be able to specify that the key
> > > > > > > is wrapped using the hardware KMK. Then if the hardware has already
> > > > > > > started using the other kind of keys, it should be able to respond
> > > > > > > with -EINVAL / whatever else. Then the user can evict previously
> > > > > > > programmed key and program a desired one.
> > > > > > >
> > > > > > > > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > > > > > > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > > > > > > > out why that's not the case?
> > > > > > > > >
> > > > > > > >
> > > > > > > > I will evaluate this.
> > > > > > > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > > > > > > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > > > > > > > driver. The interface is through QCOM SCM driver.
> > > > > > >
> > > > > > > Note, this is just an API interface, see how it is implemented for the
> > > > > > > CAAM hardware.
> > > > > > >
> > > > > >
> > > > > > The problem is that this patchset was sent out without the patches that add the
> > > > > > block and filesystem-level framework for hardware-wrapped inline encryption
> > > > > > keys, which it depends on.  So it's lacking context.  The proposed framework can
> > > > > > be found at
> > > > > > https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> > > > >
> > > > > Thank you. I have quickly skimmed through the patches, but I didn't
> > > > > review them thoroughly. Maybe the patchset already implements the
> > > > > interfaces that I'm thinking about. In such a case please excuse me. I
> > > > > will give it a more thorough look later today.
> > > > >
> > > > > > As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> > > > > > keys" are based around a model where the kernel can request that keys be sealed
> > > > > > and unsealed using a trust source, and the kernel gets access to the raw
> > > > > > unsealed keys.  Hardware-wrapped inline encryption keys use a different model
> > > > > > where the kernel never gets access to the raw keys.  They also have the concept
> > > > > > of ephemeral wrapping which does not exist in "trusted keys".  And they need to
> > > > > > be properly integrated with the inline encryption framework in the block layer.
> > > > >
> > > > > Then what exactly does qcom_scm_derive_sw_secret() do? Does it rewrap
> > > > > the key under some other key?
> > > >
> > > > It derives a secret for functionality such as filenames encryption that can't
> > > > use inline encryption.
> > > >
> > > > > I had the feeling that there are two separate pieces of functionality
> > > > > being stuffed into a single patchset and into a single solution.
> > > > >
> > > > > First one is handling the keys. I keep on thinking that there should
> > > > > be a separate software interface to unseal the key and rewrap it under
> > > > > an ephemeral key.
> > > >
> > > > There is.  That's what the BLKCRYPTOPREPAREKEY ioctl is for.
> > > >
> > > > > Some hardware might permit importing raw keys.
> > > >
> > > > That's what BLKCRYPTOIMPORTKEY is for.
> > > >
> > > > > Other hardware might insist on generating the keys on-chip so that raw keys
> > > > > can never be used.
> > > >
> > > > And that's what BLKCRYPTOGENERATEKEY is for.
> > >
> > > Again, this might be answered somewhere, but why can't we use keyctl
> > > for handling the keys and then use a single IOCTL to point the block
> > > device to the key in the keyring?
> >
> > All the same functionality would need to be supported, and I think that
> > shoehorning it into the keyrings service instead of just adding new ioctls would
> > be more difficult.  The keyrings service was not designed for this use case.
> > We've already had a lot of problems trying to take advantage of the keyrings
> > service in fscrypt previously.  The keyrings service is something that sounds
> > useful but really isn't all that useful.
> 
> I would be really interested in reading or listening to any kind of
> summary or parts of the issues.
> I'm slightly pushy towards keyctl / keyrings, because it already
> provides support for different kinds of key wrapping and key
> management. Encrypted keys, trusted keys - those are all kinds of key
> management, which either will be missing or will have to be
> reimplemented for block layers.
> 
> I know that keyrings are clumsy and not that logical, but then their
> API needs to be improved. Just ignoring the existing mechanisms sounds
> like a bad idea.

One thing to keep in mind is that keyring service keys can't be used directly
for storage encryption.  So if a component that manages storage encryption (such
as fscrypt or dm-crypt) is given a keyring service key, in practice it has to
extract the payload from the keyring service key, and not use the keyring
service key any further.  So the keyring service can, at most, serve as a way to
create and prepare the key, and after that it doesn't serve a purpose.

(fscrypt used to use the keyring service a bit more: it looked up a key whenever
a file was opened, and it supported evicting per-file keys by revoking the
corresponding keyring key.  But this turned out to be totally broken.  E.g., it
didn't provide the correct semantics for filesystem encryption where the key
should either be present or absent filesystem-wide.)

We do need the ability to create HW-wrapped keys in long-term wrapped form,
either via "generate" or "import", return those long-term wrapped keys to
userspace so that they can be stored on-disk, and convert them into
ephemerally-wrapped form so they can be used.  It probably would be possible to
support all of this through the keyrings service, but it would need a couple new
key types:

- One key type that can be instantiated with a raw key (or NULL to request
  generation of a key) and that automagically creates a long-term wrapped key
  and supports userspace reading it back.  This would be vaguely similar to
  "trusted", but without any support for using the key directly.

- One key type that can be instantiated using a long-term wrapped key which gets
  automagically converted to an ephemerally-wrapped key.  This would be what is
  passed to other kernel subsystems.  Functions specific to this key type would
  need to be provided for users to use.

I think it would be possible, but it feels like a bit of a shoehorned API.  The
ioctls are a more straightforward solution.

> >
> > By "a single IOCTL to point the block device to the key in the keyring", you
> > seem to be referring to configuring full block device encryption with a single
> > key.  That's not something that's supported by the upstream kernel yet, and it's
> > not related to this patchset; currently only fscrypt supports inline encryption.
> 
> I see that dm has at least some provisioning and hooks for
> CONFIG_BLK_INLINE_ENCRYPTION. Thus I thought that it's possible to use
> inline encryption through DM.

device-mapper supports passing through the inline encryption support of
underlying devices in certain cases, but it doesn't yet support using it itself.

> 
> > Support for it will be added at some point, which will likely indeed take the
> > form of an ioctl to set a key on a block device.  But that would be the case
> > even without HW-wrapped keys.  And *requiring* the key to be given in a keyring
> > (instead of just in a byte array passed to the ioctl) isn't very helpful, as it
> > just makes the API harder to use.  We've learned this from the fscrypt API
> > already where we actually had to move away from the keyrings service in order to
> > fix all the issues caused by it (see FS_IOC_ADD_ENCRYPTION_KEY).
> >
> > > >
> > > > > Second part is the actual block interface. Gaurav wrote about
> > > > > targeting fscrypt, but there should be no actual difference between
> > > > > crypto targets. FDE or having a single partition encrypted should
> > > > > probably work in the same way. Convert the key into blk_crypto_key
> > > > > (including the cookie for the ephemeral key), program the key into the
> > > > > slot, use the slot to en/decrypt hardware blocks.
> > > > >
> > > > > My main point is that the decision on the key type should be coming
> > > > > from the user.
> > > >
> > > > That's exactly how it works.  There is a block interface for specifying an
> > > > inline encryption key along with each bio.  The submitter of the bio can specify
> > > > either a standard key or a HW-wrapped key.
> > >
> > > Not in this patchset. The ICE driver decides whether it can support
> > > HW-wrapped keys or not and then fails to support other type of keys.
> > >
> >
> > Sure, that's just a matter of hardware capabilities though, right?  The block
> > layer provides a way for drivers to declare which inline encryption capabilities
> > they support.  They can declare they support standard keys, HW-wrapped keys,
> > both, or neither.  If Qualcomm SoCs can't support both types of keys at the same
> > time, that's unfortunate, but I'm not sure what your poitnt is.  The user (e.g.
> > fscrypt) still has control over whether they use the functionality that the
> > hardware provides.
> 
> It's a matter of policy. Harware / firmware doesn't support using both
> kinds of keys concurrently, if I understood Gaurav's explanations
> correctly. But the user should be able to make a judgement and use
> non-hw-wrapped keys if it fits their requirements. The driver should
> not make this kind of judgement. Note, this is not an issue of your
> original patchset, but it's a driver flaw in this patchset.

If the driver has to make a decision about which type of keys to support (due to
the hardware and firmware supporting both but not at the same time), I think
this will need to be done via a module parameter, e.g.
qcom_ice.hw_wrapped_keys=1 to support HW-wrapped keys instead of standard keys.

- Eric

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Fri, 21 Jun 2024 at 21:36, Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Fri, Jun 21, 2024 at 08:49:56PM +0300, Dmitry Baryshkov wrote:
> > On Fri, 21 Jun 2024 at 19:31, Eric Biggers <ebiggers@kernel.org> wrote:
> > >
> > > On Fri, Jun 21, 2024 at 07:06:25PM +0300, Dmitry Baryshkov wrote:
> > > > On Fri, 21 Jun 2024 at 18:39, Eric Biggers <ebiggers@kernel.org> wrote:
> > > > >
> > > > > On Fri, Jun 21, 2024 at 06:16:37PM +0300, Dmitry Baryshkov wrote:
> > > > > > On Fri, 21 Jun 2024 at 07:47, Eric Biggers <ebiggers@kernel.org> wrote:
> > > > > > >
> > > > > > > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Is it possible to use both kind of keys when working on standard mode?
> > > > > > > > > > > > If not, it should be the user who selects what type of keys to be used.
> > > > > > > > > > > > Enforcing this via DT is not a way to go.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Unfortunately, that support is not there yet. When you say user, do
> > > > > > > > > > > you mean to have it as a filesystem mount option?
> > > > > > > > > >
> > > > > > > > > > During cryptsetup time. When running e.g. cryptsetup I, as a user, would like
> > > > > > > > > > to be able to use either a hardware-wrapped key or a standard key.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > What we are looking for with these patches is for per-file/folder encryption using fscrypt policies.
> > > > > > > > > Cryptsetup to my understanding supports only full-disk , and does not support FBE (File-Based)
> > > > > > > >
> > > > > > > > I must admit, I mostly used dm-crypt beforehand, so I had to look at
> > > > > > > > fscrypt now. Some of my previous comments might not be fully
> > > > > > > > applicable.
> > > > > > > >
> > > > > > > > > Hence the idea here is that we mount an unencrypted device (with the inlinecrypt option that indicates inline encryption is supported)
> > > > > > > > > And specify policies (links to keys) for different folders.
> > > > > > > > >
> > > > > > > > > > > The way the UFS/EMMC crypto layer is designed currently is that, this
> > > > > > > > > > > information is needed when the modules are loaded.
> > > > > > > > > > >
> > > > > > > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org
> > > > > > > > > > > /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > > > > > > >
> > > > > > > > > > I see that the driver lists capabilities here. E.g. that it supports HW-wrapped
> > > > > > > > > > keys. But the line doesn't specify that standard keys are not supported.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Those are capabilities that are read from the storage controller. However, wrapped keys
> > > > > > > > > Are not a standard in the ICE JEDEC specification, and in most cases, is a value add coming
> > > > > > > > > from the SoC.
> > > > > > > > >
> > > > > > > > > QCOM SOC and firmware currently does not support both kinds of keys in the HWKM mode.
> > > > > > > > > That is something we are internally working on, but not available yet.
> > > > > > > >
> > > > > > > > I'd say this is a significant obstacle, at least from my point of
> > > > > > > > view. I understand that the default might be to use hw-wrapped keys,
> > > > > > > > but it should be possible for the user to select non-HW keys if the
> > > > > > > > ability to recover the data is considered to be important. Note, I'm
> > > > > > > > really pointing to the user here, not to the system integrator. So
> > > > > > > > using DT property or specifying kernel arguments to switch between
> > > > > > > > these modes is not really an option.
> > > > > > > >
> > > > > > > > But I'd really love to hear some feedback from linux-security and/or
> > > > > > > > linux-fscrypt here.
> > > > > > > >
> > > > > > > > In my humble opinion the user should be able to specify that the key
> > > > > > > > is wrapped using the hardware KMK. Then if the hardware has already
> > > > > > > > started using the other kind of keys, it should be able to respond
> > > > > > > > with -EINVAL / whatever else. Then the user can evict previously
> > > > > > > > programmed key and program a desired one.
> > > > > > > >
> > > > > > > > > > Also, I'd have expected that hw-wrapped keys are handled using trusted
> > > > > > > > > > keys mechanism (see security/keys/trusted-keys/). Could you please point
> > > > > > > > > > out why that's not the case?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I will evaluate this.
> > > > > > > > > But my initial response is that we currently cannot communicate to our TPM directly from HLOS, but
> > > > > > > > > goes through QTEE, and I don't think our qtee currently interfaces with the open source tee
> > > > > > > > > driver. The interface is through QCOM SCM driver.
> > > > > > > >
> > > > > > > > Note, this is just an API interface, see how it is implemented for the
> > > > > > > > CAAM hardware.
> > > > > > > >
> > > > > > >
> > > > > > > The problem is that this patchset was sent out without the patches that add the
> > > > > > > block and filesystem-level framework for hardware-wrapped inline encryption
> > > > > > > keys, which it depends on.  So it's lacking context.  The proposed framework can
> > > > > > > be found at
> > > > > > > https://lore.kernel.org/linux-block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> > > > > >
> > > > > > Thank you. I have quickly skimmed through the patches, but I didn't
> > > > > > review them thoroughly. Maybe the patchset already implements the
> > > > > > interfaces that I'm thinking about. In such a case please excuse me. I
> > > > > > will give it a more thorough look later today.
> > > > > >
> > > > > > > As for why "trusted keys" aren't used, they just aren't helpful here.  "Trusted
> > > > > > > keys" are based around a model where the kernel can request that keys be sealed
> > > > > > > and unsealed using a trust source, and the kernel gets access to the raw
> > > > > > > unsealed keys.  Hardware-wrapped inline encryption keys use a different model
> > > > > > > where the kernel never gets access to the raw keys.  They also have the concept
> > > > > > > of ephemeral wrapping which does not exist in "trusted keys".  And they need to
> > > > > > > be properly integrated with the inline encryption framework in the block layer.
> > > > > >
> > > > > > Then what exactly does qcom_scm_derive_sw_secret() do? Does it rewrap
> > > > > > the key under some other key?
> > > > >
> > > > > It derives a secret for functionality such as filenames encryption that can't
> > > > > use inline encryption.
> > > > >
> > > > > > I had the feeling that there are two separate pieces of functionality
> > > > > > being stuffed into a single patchset and into a single solution.
> > > > > >
> > > > > > First one is handling the keys. I keep on thinking that there should
> > > > > > be a separate software interface to unseal the key and rewrap it under
> > > > > > an ephemeral key.
> > > > >
> > > > > There is.  That's what the BLKCRYPTOPREPAREKEY ioctl is for.
> > > > >
> > > > > > Some hardware might permit importing raw keys.
> > > > >
> > > > > That's what BLKCRYPTOIMPORTKEY is for.
> > > > >
> > > > > > Other hardware might insist on generating the keys on-chip so that raw keys
> > > > > > can never be used.
> > > > >
> > > > > And that's what BLKCRYPTOGENERATEKEY is for.
> > > >
> > > > Again, this might be answered somewhere, but why can't we use keyctl
> > > > for handling the keys and then use a single IOCTL to point the block
> > > > device to the key in the keyring?
> > >
> > > All the same functionality would need to be supported, and I think that
> > > shoehorning it into the keyrings service instead of just adding new ioctls would
> > > be more difficult.  The keyrings service was not designed for this use case.
> > > We've already had a lot of problems trying to take advantage of the keyrings
> > > service in fscrypt previously.  The keyrings service is something that sounds
> > > useful but really isn't all that useful.
> >
> > I would be really interested in reading or listening to any kind of
> > summary or parts of the issues.
> > I'm slightly pushy towards keyctl / keyrings, because it already
> > provides support for different kinds of key wrapping and key
> > management. Encrypted keys, trusted keys - those are all kinds of key
> > management, which either will be missing or will have to be
> > reimplemented for block layers.
> >
> > I know that keyrings are clumsy and not that logical, but then their
> > API needs to be improved. Just ignoring the existing mechanisms sounds
> > like a bad idea.
>
> One thing to keep in mind is that keyring service keys can't be used directly
> for storage encryption.  So if a component that manages storage encryption (such
> as fscrypt or dm-crypt) is given a keyring service key, in practice it has to
> extract the payload from the keyring service key, and not use the keyring
> service key any further.  So the keyring service can, at most, serve as a way to
> create and prepare the key, and after that it doesn't serve a purpose.

Yes, this sounds good enough.

>
> (fscrypt used to use the keyring service a bit more: it looked up a key whenever
> a file was opened, and it supported evicting per-file keys by revoking the
> corresponding keyring key.  But this turned out to be totally broken.  E.g., it
> didn't provide the correct semantics for filesystem encryption where the key
> should either be present or absent filesystem-wide.)
>
> We do need the ability to create HW-wrapped keys in long-term wrapped form,
> either via "generate" or "import", return those long-term wrapped keys to
> userspace so that they can be stored on-disk, and convert them into
> ephemerally-wrapped form so they can be used.  It probably would be possible to
> support all of this through the keyrings service, but it would need a couple new
> key types:
>
> - One key type that can be instantiated with a raw key (or NULL to request
>   generation of a key) and that automagically creates a long-term wrapped key
>   and supports userspace reading it back.  This would be vaguely similar to
>   "trusted", but without any support for using the key directly.
>
> - One key type that can be instantiated using a long-term wrapped key which gets
>   automagically converted to an ephemerally-wrapped key.  This would be what is
>   passed to other kernel subsystems.  Functions specific to this key type would
>   need to be provided for users to use.

I think having one key type should be enough. The userspace loads /
generates&reads / wraps and reads back the 'exported' version wrapped
using the platform-specific key. In kernel the key is unsealed and
represented as binary key to be loaded to the hardware + a cookie for
the ephemeral key and device that have been used to wrap it. When
userspace asks the device to program the key, the cookie is verified
to match the device / ephemeral key and then the binary is programmed
to the hardware. Maybe it's enough to use the struct device as a
cookie.

> I think it would be possible, but it feels like a bit of a shoehorned API.  The
> ioctls are a more straightforward solution.

Are we going to have another set of IOCTLs for loading the encrypted
keys? keys sealed by TPM?

> > > By "a single IOCTL to point the block device to the key in the keyring", you
> > > seem to be referring to configuring full block device encryption with a single
> > > key.  That's not something that's supported by the upstream kernel yet, and it's
> > > not related to this patchset; currently only fscrypt supports inline encryption.
> >
> > I see that dm has at least some provisioning and hooks for
> > CONFIG_BLK_INLINE_ENCRYPTION. Thus I thought that it's possible to use
> > inline encryption through DM.
>
> device-mapper supports passing through the inline encryption support of
> underlying devices in certain cases, but it doesn't yet support using it itself.

I see. I was confused by the dm code then. Please excuse me.

>
> >
> > > Support for it will be added at some point, which will likely indeed take the
> > > form of an ioctl to set a key on a block device.  But that would be the case
> > > even without HW-wrapped keys.  And *requiring* the key to be given in a keyring
> > > (instead of just in a byte array passed to the ioctl) isn't very helpful, as it
> > > just makes the API harder to use.  We've learned this from the fscrypt API
> > > already where we actually had to move away from the keyrings service in order to
> > > fix all the issues caused by it (see FS_IOC_ADD_ENCRYPTION_KEY).
> > >
> > > > >
> > > > > > Second part is the actual block interface. Gaurav wrote about
> > > > > > targeting fscrypt, but there should be no actual difference between
> > > > > > crypto targets. FDE or having a single partition encrypted should
> > > > > > probably work in the same way. Convert the key into blk_crypto_key
> > > > > > (including the cookie for the ephemeral key), program the key into the
> > > > > > slot, use the slot to en/decrypt hardware blocks.
> > > > > >
> > > > > > My main point is that the decision on the key type should be coming
> > > > > > from the user.
> > > > >
> > > > > That's exactly how it works.  There is a block interface for specifying an
> > > > > inline encryption key along with each bio.  The submitter of the bio can specify
> > > > > either a standard key or a HW-wrapped key.
> > > >
> > > > Not in this patchset. The ICE driver decides whether it can support
> > > > HW-wrapped keys or not and then fails to support other type of keys.
> > > >
> > >
> > > Sure, that's just a matter of hardware capabilities though, right?  The block
> > > layer provides a way for drivers to declare which inline encryption capabilities
> > > they support.  They can declare they support standard keys, HW-wrapped keys,
> > > both, or neither.  If Qualcomm SoCs can't support both types of keys at the same
> > > time, that's unfortunate, but I'm not sure what your poitnt is.  The user (e.g.
> > > fscrypt) still has control over whether they use the functionality that the
> > > hardware provides.
> >
> > It's a matter of policy. Harware / firmware doesn't support using both
> > kinds of keys concurrently, if I understood Gaurav's explanations
> > correctly. But the user should be able to make a judgement and use
> > non-hw-wrapped keys if it fits their requirements. The driver should
> > not make this kind of judgement. Note, this is not an issue of your
> > original patchset, but it's a driver flaw in this patchset.
>
> If the driver has to make a decision about which type of keys to support (due to
> the hardware and firmware supporting both but not at the same time), I think
> this will need to be done via a module parameter, e.g.
> qcom_ice.hw_wrapped_keys=1 to support HW-wrapped keys instead of standard keys.

No, the user can not set modparams on  e.g. Android device. In my
opinion it should be first-come-first-serve. If the user wants
hw-wrapped keys (and the platform is fine with that), then further
attempts to use raw keys should fail. If the user loads a raw key,
further attempts to set hw-wrapped key should fail (maybe until the
last raw key has been evicted from the hw, if such thing is actually
supported).

-- 
With best wishes
Dmitry

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Eric Biggers]

On Fri, Jun 21, 2024 at 10:24:07PM +0300, Dmitry Baryshkov wrote:
> >
> > (fscrypt used to use the keyring service a bit more: it looked up a key whenever
> > a file was opened, and it supported evicting per-file keys by revoking the
> > corresponding keyring key.  But this turned out to be totally broken.  E.g., it
> > didn't provide the correct semantics for filesystem encryption where the key
> > should either be present or absent filesystem-wide.)
> >
> > We do need the ability to create HW-wrapped keys in long-term wrapped form,
> > either via "generate" or "import", return those long-term wrapped keys to
> > userspace so that they can be stored on-disk, and convert them into
> > ephemerally-wrapped form so they can be used.  It probably would be possible to
> > support all of this through the keyrings service, but it would need a couple new
> > key types:
> >
> > - One key type that can be instantiated with a raw key (or NULL to request
> >   generation of a key) and that automagically creates a long-term wrapped key
> >   and supports userspace reading it back.  This would be vaguely similar to
> >   "trusted", but without any support for using the key directly.
> >
> > - One key type that can be instantiated using a long-term wrapped key which gets
> >   automagically converted to an ephemerally-wrapped key.  This would be what is
> >   passed to other kernel subsystems.  Functions specific to this key type would
> >   need to be provided for users to use.
> 
> I think having one key type should be enough. The userspace loads /
> generates&reads / wraps and reads back the 'exported' version wrapped
> using the platform-specific key. In kernel the key is unsealed and
> represented as binary key to be loaded to the hardware + a cookie for
> the ephemeral key and device that have been used to wrap it. When
> userspace asks the device to program the key, the cookie is verified
> to match the device / ephemeral key and then the binary is programmed
> to the hardware. Maybe it's enough to use the struct device as a
> cookie.

The long-term wrapped key has to be wiped from memory as soon as it's no longer
needed.  So it's hard to see how overloading a key type in this way can work, as
the kernel can't know if userspace intends to read back the long-term wrapped
key or not.

> 
> > I think it would be possible, but it feels like a bit of a shoehorned API.  The
> > ioctls are a more straightforward solution.
> 
> Are we going to have another set of IOCTLs for loading the encrypted
> keys? keys sealed by TPM?

Those features aren't compatible with hardware-wrapped inline encryption keys,
so they're not really relevant here.  BLKCRYPTOIMPORTKEY could support importing
a keyring service key as an alternative to a raw key, of course.  But this would
just work similarly to fscrypt and dm-crypt where they just extract the payload,
and the keyring service key plays no further role.

> > > > Support for it will be added at some point, which will likely indeed take the
> > > > form of an ioctl to set a key on a block device.  But that would be the case
> > > > even without HW-wrapped keys.  And *requiring* the key to be given in a keyring
> > > > (instead of just in a byte array passed to the ioctl) isn't very helpful, as it
> > > > just makes the API harder to use.  We've learned this from the fscrypt API
> > > > already where we actually had to move away from the keyrings service in order to
> > > > fix all the issues caused by it (see FS_IOC_ADD_ENCRYPTION_KEY).
> > > >
> > > > > >
> > > > > > > Second part is the actual block interface. Gaurav wrote about
> > > > > > > targeting fscrypt, but there should be no actual difference between
> > > > > > > crypto targets. FDE or having a single partition encrypted should
> > > > > > > probably work in the same way. Convert the key into blk_crypto_key
> > > > > > > (including the cookie for the ephemeral key), program the key into the
> > > > > > > slot, use the slot to en/decrypt hardware blocks.
> > > > > > >
> > > > > > > My main point is that the decision on the key type should be coming
> > > > > > > from the user.
> > > > > >
> > > > > > That's exactly how it works.  There is a block interface for specifying an
> > > > > > inline encryption key along with each bio.  The submitter of the bio can specify
> > > > > > either a standard key or a HW-wrapped key.
> > > > >
> > > > > Not in this patchset. The ICE driver decides whether it can support
> > > > > HW-wrapped keys or not and then fails to support other type of keys.
> > > > >
> > > >
> > > > Sure, that's just a matter of hardware capabilities though, right?  The block
> > > > layer provides a way for drivers to declare which inline encryption capabilities
> > > > they support.  They can declare they support standard keys, HW-wrapped keys,
> > > > both, or neither.  If Qualcomm SoCs can't support both types of keys at the same
> > > > time, that's unfortunate, but I'm not sure what your poitnt is.  The user (e.g.
> > > > fscrypt) still has control over whether they use the functionality that the
> > > > hardware provides.
> > >
> > > It's a matter of policy. Harware / firmware doesn't support using both
> > > kinds of keys concurrently, if I understood Gaurav's explanations
> > > correctly. But the user should be able to make a judgement and use
> > > non-hw-wrapped keys if it fits their requirements. The driver should
> > > not make this kind of judgement. Note, this is not an issue of your
> > > original patchset, but it's a driver flaw in this patchset.
> >
> > If the driver has to make a decision about which type of keys to support (due to
> > the hardware and firmware supporting both but not at the same time), I think
> > this will need to be done via a module parameter, e.g.
> > qcom_ice.hw_wrapped_keys=1 to support HW-wrapped keys instead of standard keys.
> 
> No, the user can not set modparams on  e.g. Android device. In my
> opinion it should be first-come-first-serve. If the user wants
> hw-wrapped keys (and the platform is fine with that), then further
> attempts to use raw keys should fail. If the user loads a raw key,
> further attempts to set hw-wrapped key should fail (maybe until the
> last raw key has been evicted from the hw, if such thing is actually
> supported).

That's not going to work.  Upper layers need to know what the crypto
capabilities are before they decide to use them.  We can't randomly revoke
capabilities based on who happened to get there first, as a user might have
already checked the capabilities.  Yes, the module parameter is a litle
annoying, but it seems to be necessary here.  It is not a problem for Android
because the type of encryption an Android device uses is set by the build
anyway, which makes it no easier to change than module parameters.

- Eric

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Dmitry Baryshkov]

On Fri, Jun 21, 2024 at 08:14:41PM GMT, Eric Biggers wrote:
> On Fri, Jun 21, 2024 at 10:24:07PM +0300, Dmitry Baryshkov wrote:
> > >
> > > (fscrypt used to use the keyring service a bit more: it looked up a key whenever
> > > a file was opened, and it supported evicting per-file keys by revoking the
> > > corresponding keyring key.  But this turned out to be totally broken.  E.g., it
> > > didn't provide the correct semantics for filesystem encryption where the key
> > > should either be present or absent filesystem-wide.)
> > >
> > > We do need the ability to create HW-wrapped keys in long-term wrapped form,
> > > either via "generate" or "import", return those long-term wrapped keys to
> > > userspace so that they can be stored on-disk, and convert them into
> > > ephemerally-wrapped form so they can be used.  It probably would be possible to
> > > support all of this through the keyrings service, but it would need a couple new
> > > key types:
> > >
> > > - One key type that can be instantiated with a raw key (or NULL to request
> > >   generation of a key) and that automagically creates a long-term wrapped key
> > >   and supports userspace reading it back.  This would be vaguely similar to
> > >   "trusted", but without any support for using the key directly.
> > >
> > > - One key type that can be instantiated using a long-term wrapped key which gets
> > >   automagically converted to an ephemerally-wrapped key.  This would be what is
> > >   passed to other kernel subsystems.  Functions specific to this key type would
> > >   need to be provided for users to use.
> > 
> > I think having one key type should be enough. The userspace loads /
> > generates&reads / wraps and reads back the 'exported' version wrapped
> > using the platform-specific key. In kernel the key is unsealed and
> > represented as binary key to be loaded to the hardware + a cookie for
> > the ephemeral key and device that have been used to wrap it. When
> > userspace asks the device to program the key, the cookie is verified
> > to match the device / ephemeral key and then the binary is programmed
> > to the hardware. Maybe it's enough to use the struct device as a
> > cookie.
> 
> The long-term wrapped key has to be wiped from memory as soon as it's no longer
> needed.  So it's hard to see how overloading a key type in this way can work, as
> the kernel can't know if userspace intends to read back the long-term wrapped
> key or not.

Why? It should be user's decision. Pretty much in the same way as it's
done for all other keys.

> > > I think it would be possible, but it feels like a bit of a shoehorned API.  The
> > > ioctls are a more straightforward solution.
> > 
> > Are we going to have another set of IOCTLs for loading the encrypted
> > keys? keys sealed by TPM?
> 
> Those features aren't compatible with hardware-wrapped inline encryption keys,
> so they're not really relevant here.  BLKCRYPTOIMPORTKEY could support importing
> a keyring service key as an alternative to a raw key, of course.  But this would
> just work similarly to fscrypt and dm-crypt where they just extract the payload,
> and the keyring service key plays no further role.

Yes, extracting the payload is fine. As you wrote, dm-crypt and fscrypt
already do it in this way. But what I really don't like here is the idea
of having two different kinds of API having pretty close functionality.
In my opinion, all the keys should be handled via the existing keyrings
API and then imported via the BLKCRYPTOIMPORTKEY IOCTL. This way all
kinds of keys are handled in a similar way from user's point of view.

> > > > > Support for it will be added at some point, which will likely indeed take the
> > > > > form of an ioctl to set a key on a block device.  But that would be the case
> > > > > even without HW-wrapped keys.  And *requiring* the key to be given in a keyring
> > > > > (instead of just in a byte array passed to the ioctl) isn't very helpful, as it
> > > > > just makes the API harder to use.  We've learned this from the fscrypt API
> > > > > already where we actually had to move away from the keyrings service in order to
> > > > > fix all the issues caused by it (see FS_IOC_ADD_ENCRYPTION_KEY).
> > > > >
> > > > > > >
> > > > > > > > Second part is the actual block interface. Gaurav wrote about
> > > > > > > > targeting fscrypt, but there should be no actual difference between
> > > > > > > > crypto targets. FDE or having a single partition encrypted should
> > > > > > > > probably work in the same way. Convert the key into blk_crypto_key
> > > > > > > > (including the cookie for the ephemeral key), program the key into the
> > > > > > > > slot, use the slot to en/decrypt hardware blocks.
> > > > > > > >
> > > > > > > > My main point is that the decision on the key type should be coming
> > > > > > > > from the user.
> > > > > > >
> > > > > > > That's exactly how it works.  There is a block interface for specifying an
> > > > > > > inline encryption key along with each bio.  The submitter of the bio can specify
> > > > > > > either a standard key or a HW-wrapped key.
> > > > > >
> > > > > > Not in this patchset. The ICE driver decides whether it can support
> > > > > > HW-wrapped keys or not and then fails to support other type of keys.
> > > > > >
> > > > >
> > > > > Sure, that's just a matter of hardware capabilities though, right?  The block
> > > > > layer provides a way for drivers to declare which inline encryption capabilities
> > > > > they support.  They can declare they support standard keys, HW-wrapped keys,
> > > > > both, or neither.  If Qualcomm SoCs can't support both types of keys at the same
> > > > > time, that's unfortunate, but I'm not sure what your poitnt is.  The user (e.g.
> > > > > fscrypt) still has control over whether they use the functionality that the
> > > > > hardware provides.
> > > >
> > > > It's a matter of policy. Harware / firmware doesn't support using both
> > > > kinds of keys concurrently, if I understood Gaurav's explanations
> > > > correctly. But the user should be able to make a judgement and use
> > > > non-hw-wrapped keys if it fits their requirements. The driver should
> > > > not make this kind of judgement. Note, this is not an issue of your
> > > > original patchset, but it's a driver flaw in this patchset.
> > >
> > > If the driver has to make a decision about which type of keys to support (due to
> > > the hardware and firmware supporting both but not at the same time), I think
> > > this will need to be done via a module parameter, e.g.
> > > qcom_ice.hw_wrapped_keys=1 to support HW-wrapped keys instead of standard keys.
> > 
> > No, the user can not set modparams on  e.g. Android device. In my
> > opinion it should be first-come-first-serve. If the user wants
> > hw-wrapped keys (and the platform is fine with that), then further
> > attempts to use raw keys should fail. If the user loads a raw key,
> > further attempts to set hw-wrapped key should fail (maybe until the
> > last raw key has been evicted from the hw, if such thing is actually
> > supported).
> 
> That's not going to work.  Upper layers need to know what the crypto
> capabilities are before they decide to use them.  We can't randomly revoke
> capabilities based on who happened to get there first, as a user might have
> already checked the capabilities.  Yes, the module parameter is a litle
> annoying, but it seems to be necessary here.

Hmm. This is typical to have resource-limited capabilities. So yes, the
user checks the capabilities to identify whether the key type is
supported at all. But then _using_ the key might fail. For example
because all the hardware resources that are used by this key type are
already taken.

> It is not a problem for Android
> because the type of encryption an Android device uses is set by the build
> anyway, which makes it no easier to change than module parameters.

If AOSP misbehaves, it doesn't mean that we should follow the pattern.

-- 
With best wishes
Dmitry

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Eric Biggers]

On Fri, Jun 21, 2024 at 11:52:01PM +0300, Dmitry Baryshkov wrote:
> On Fri, Jun 21, 2024 at 08:14:41PM GMT, Eric Biggers wrote:
> > On Fri, Jun 21, 2024 at 10:24:07PM +0300, Dmitry Baryshkov wrote:
> > > >
> > > > (fscrypt used to use the keyring service a bit more: it looked up a key whenever
> > > > a file was opened, and it supported evicting per-file keys by revoking the
> > > > corresponding keyring key.  But this turned out to be totally broken.  E.g., it
> > > > didn't provide the correct semantics for filesystem encryption where the key
> > > > should either be present or absent filesystem-wide.)
> > > >
> > > > We do need the ability to create HW-wrapped keys in long-term wrapped form,
> > > > either via "generate" or "import", return those long-term wrapped keys to
> > > > userspace so that they can be stored on-disk, and convert them into
> > > > ephemerally-wrapped form so they can be used.  It probably would be possible to
> > > > support all of this through the keyrings service, but it would need a couple new
> > > > key types:
> > > >
> > > > - One key type that can be instantiated with a raw key (or NULL to request
> > > >   generation of a key) and that automagically creates a long-term wrapped key
> > > >   and supports userspace reading it back.  This would be vaguely similar to
> > > >   "trusted", but without any support for using the key directly.
> > > >
> > > > - One key type that can be instantiated using a long-term wrapped key which gets
> > > >   automagically converted to an ephemerally-wrapped key.  This would be what is
> > > >   passed to other kernel subsystems.  Functions specific to this key type would
> > > >   need to be provided for users to use.
> > > 
> > > I think having one key type should be enough. The userspace loads /
> > > generates&reads / wraps and reads back the 'exported' version wrapped
> > > using the platform-specific key. In kernel the key is unsealed and
> > > represented as binary key to be loaded to the hardware + a cookie for
> > > the ephemeral key and device that have been used to wrap it. When
> > > userspace asks the device to program the key, the cookie is verified
> > > to match the device / ephemeral key and then the binary is programmed
> > > to the hardware. Maybe it's enough to use the struct device as a
> > > cookie.
> > 
> > The long-term wrapped key has to be wiped from memory as soon as it's no longer
> > needed.  So it's hard to see how overloading a key type in this way can work, as
> > the kernel can't know if userspace intends to read back the long-term wrapped
> > key or not.
> 
> Why? It should be user's decision. Pretty much in the same way as it's
> done for all other keys.

Sorry, I don't understand what your point is supposed to be here.  It's
certainly not okay to leave the long-term wrapped key in memory, since that
destroys the security properties of hardware-wrapped keys.  So we need to
provide an API that makes it possible for the long-term wrapped key to be
zeroized.  The API you're proposing, as I understand it, wouldn't allow for that
because the long-term wrapped key would remain in memory as long as the keyring
service key exists, even when only the ephemerally-wrapped key is needed.

> 
> > > > I think it would be possible, but it feels like a bit of a shoehorned API.  The
> > > > ioctls are a more straightforward solution.
> > > 
> > > Are we going to have another set of IOCTLs for loading the encrypted
> > > keys? keys sealed by TPM?
> > 
> > Those features aren't compatible with hardware-wrapped inline encryption keys,
> > so they're not really relevant here.  BLKCRYPTOIMPORTKEY could support importing
> > a keyring service key as an alternative to a raw key, of course.  But this would
> > just work similarly to fscrypt and dm-crypt where they just extract the payload,
> > and the keyring service key plays no further role.
> 
> Yes, extracting the payload is fine. As you wrote, dm-crypt and fscrypt
> already do it in this way. But what I really don't like here is the idea
> of having two different kinds of API having pretty close functionality.
> In my opinion, all the keys should be handled via the existing keyrings
> API and then imported via the BLKCRYPTOIMPORTKEY IOCTL. This way all
> kinds of keys are handled in a similar way from user's point of view.

But in that case all the proposed new BLKCRYPTO* ioctls are still needed.  Your
suggestion would just make them harder to use by requiring users to copy their
key into a keyrings service key instead of just providing it directly in the
ioctl.

> 
> > > > > > Support for it will be added at some point, which will likely indeed take the
> > > > > > form of an ioctl to set a key on a block device.  But that would be the case
> > > > > > even without HW-wrapped keys.  And *requiring* the key to be given in a keyring
> > > > > > (instead of just in a byte array passed to the ioctl) isn't very helpful, as it
> > > > > > just makes the API harder to use.  We've learned this from the fscrypt API
> > > > > > already where we actually had to move away from the keyrings service in order to
> > > > > > fix all the issues caused by it (see FS_IOC_ADD_ENCRYPTION_KEY).
> > > > > >
> > > > > > > >
> > > > > > > > > Second part is the actual block interface. Gaurav wrote about
> > > > > > > > > targeting fscrypt, but there should be no actual difference between
> > > > > > > > > crypto targets. FDE or having a single partition encrypted should
> > > > > > > > > probably work in the same way. Convert the key into blk_crypto_key
> > > > > > > > > (including the cookie for the ephemeral key), program the key into the
> > > > > > > > > slot, use the slot to en/decrypt hardware blocks.
> > > > > > > > >
> > > > > > > > > My main point is that the decision on the key type should be coming
> > > > > > > > > from the user.
> > > > > > > >
> > > > > > > > That's exactly how it works.  There is a block interface for specifying an
> > > > > > > > inline encryption key along with each bio.  The submitter of the bio can specify
> > > > > > > > either a standard key or a HW-wrapped key.
> > > > > > >
> > > > > > > Not in this patchset. The ICE driver decides whether it can support
> > > > > > > HW-wrapped keys or not and then fails to support other type of keys.
> > > > > > >
> > > > > >
> > > > > > Sure, that's just a matter of hardware capabilities though, right?  The block
> > > > > > layer provides a way for drivers to declare which inline encryption capabilities
> > > > > > they support.  They can declare they support standard keys, HW-wrapped keys,
> > > > > > both, or neither.  If Qualcomm SoCs can't support both types of keys at the same
> > > > > > time, that's unfortunate, but I'm not sure what your poitnt is.  The user (e.g.
> > > > > > fscrypt) still has control over whether they use the functionality that the
> > > > > > hardware provides.
> > > > >
> > > > > It's a matter of policy. Harware / firmware doesn't support using both
> > > > > kinds of keys concurrently, if I understood Gaurav's explanations
> > > > > correctly. But the user should be able to make a judgement and use
> > > > > non-hw-wrapped keys if it fits their requirements. The driver should
> > > > > not make this kind of judgement. Note, this is not an issue of your
> > > > > original patchset, but it's a driver flaw in this patchset.
> > > >
> > > > If the driver has to make a decision about which type of keys to support (due to
> > > > the hardware and firmware supporting both but not at the same time), I think
> > > > this will need to be done via a module parameter, e.g.
> > > > qcom_ice.hw_wrapped_keys=1 to support HW-wrapped keys instead of standard keys.
> > > 
> > > No, the user can not set modparams on  e.g. Android device. In my
> > > opinion it should be first-come-first-serve. If the user wants
> > > hw-wrapped keys (and the platform is fine with that), then further
> > > attempts to use raw keys should fail. If the user loads a raw key,
> > > further attempts to set hw-wrapped key should fail (maybe until the
> > > last raw key has been evicted from the hw, if such thing is actually
> > > supported).
> > 
> > That's not going to work.  Upper layers need to know what the crypto
> > capabilities are before they decide to use them.  We can't randomly revoke
> > capabilities based on who happened to get there first, as a user might have
> > already checked the capabilities.  Yes, the module parameter is a litle
> > annoying, but it seems to be necessary here.
> 
> Hmm. This is typical to have resource-limited capabilities. So yes, the
> user checks the capabilities to identify whether the key type is
> supported at all. But then _using_ the key might fail. For example
> because all the hardware resources that are used by this key type are
> already taken.

That mustn't happen here, since finding out in the middle of an I/O request that
inline encryption isn't supported is too late.  That's what the crypto
capabilities in struct blk_crypto_profile are for -- to allow users to check
what is supported before trying to use it.

> 
> > It is not a problem for Android
> > because the type of encryption an Android device uses is set by the build
> > anyway, which makes it no easier to change than module parameters.
> 
> If AOSP misbehaves, it doesn't mean that we should follow the pattern.

It's not "misbehaving" -- it's just an example of a system that configures the
encryption centrally, which is common.  (And the reason I brought up that the
module parameter works for Android is because you claimed it wouldn't.)

Again, needing a module parameter is unfortunate but I don't see any realistic
way around it for these Qualcomm SoCs.

- Eric

RE: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[Gaurav Kashyap (QUIC)]

Hey Eric

On 06/21/2024, 9:02 AM PDT, Eric Biggers wrote:
> On Fri, Jun 21, 2024 at 03:35:40PM +0000, Gaurav Kashyap wrote:
> > Hello Eric
> >
> > On 06/20/2024, 9:48 PM PDT, Eric Biggers wrote:
> > > On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
> > > > > > >
> > > > > > > > Is it possible to use both kind of keys when working on
> > > > > > > > standard
> > > mode?
> > > > > > > > If not, it should be the user who selects what type of
> > > > > > > > keys to be
> > > used.
> > > > > > > > Enforcing this via DT is not a way to go.
> > > > > > > >
> > > > > > >
> > > > > > > Unfortunately, that support is not there yet. When you say
> > > > > > > user, do you mean to have it as a filesystem mount option?
> > > > > >
> > > > > > During cryptsetup time. When running e.g. cryptsetup I, as a
> > > > > > user, would like to be able to use either a hardware-wrapped
> > > > > > key or a
> > > standard key.
> > > > > >
> > > > >
> > > > > What we are looking for with these patches is for
> > > > > per-file/folder
> > > encryption using fscrypt policies.
> > > > > Cryptsetup to my understanding supports only full-disk , and
> > > > > does not support FBE (File-Based)
> > > >
> > > > I must admit, I mostly used dm-crypt beforehand, so I had to look
> > > > at fscrypt now. Some of my previous comments might not be fully
> > > > applicable.
> > > >
> > > > > Hence the idea here is that we mount an unencrypted device (with
> > > > > the inlinecrypt option that indicates inline encryption is
> > > > > supported) And
> > > specify policies (links to keys) for different folders.
> > > > >
> > > > > > > The way the UFS/EMMC crypto layer is designed currently is
> > > > > > > that, this information is needed when the modules are loaded.
> > > > > > >
> > > > > > > https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@
> > > > > > > kern el.org /#Z31drivers:ufs:core:ufshcd-crypto.c
> > > > > >
> > > > > > I see that the driver lists capabilities here. E.g. that it
> > > > > > supports HW-wrapped keys. But the line doesn't specify that
> > > > > > standard
> > > keys are not supported.
> > > > > >
> > > > >
> > > > > Those are capabilities that are read from the storage controller.
> > > > > However, wrapped keys Are not a standard in the ICE JEDEC
> > > > > specification, and in most cases, is a value add coming from the SoC.
> > > > >
> > > > > QCOM SOC and firmware currently does not support both kinds of
> > > > > keys in
> > > the HWKM mode.
> > > > > That is something we are internally working on, but not available yet.
> > > >
> > > > I'd say this is a significant obstacle, at least from my point of
> > > > view. I understand that the default might be to use hw-wrapped
> > > > keys, but it should be possible for the user to select non-HW keys
> > > > if the ability to recover the data is considered to be important.
> > > > Note, I'm really pointing to the user here, not to the system
> > > > integrator. So using DT property or specifying kernel arguments to
> > > > switch between these modes is not really an option.
> > > >
> > > > But I'd really love to hear some feedback from linux-security
> > > > and/or linux-fscrypt here.
> > > >
> > > > In my humble opinion the user should be able to specify that the
> > > > key is wrapped using the hardware KMK. Then if the hardware has
> > > > already started using the other kind of keys, it should be able to
> > > > respond with -EINVAL / whatever else. Then the user can evict
> > > > previously programmed key and program a desired one.
> > > >
> > > > > > Also, I'd have expected that hw-wrapped keys are handled using
> > > > > > trusted keys mechanism (see security/keys/trusted-keys/).
> > > > > > Could you please point out why that's not the case?
> > > > > >
> > > > >
> > > > > I will evaluate this.
> > > > > But my initial response is that we currently cannot communicate
> > > > > to our TPM directly from HLOS, but goes through QTEE, and I
> > > > > don't think our qtee currently interfaces with the open source
> > > > > tee driver. The
> > > interface is through QCOM SCM driver.
> > > >
> > > > Note, this is just an API interface, see how it is implemented for
> > > > the CAAM hardware.
> > > >
> > >
> > > The problem is that this patchset was sent out without the patches
> > > that add the block and filesystem-level framework for
> > > hardware-wrapped inline encryption keys, which it depends on.  So
> > > it's lacking context.  The proposed framework can be found at
> > > https://lore.kernel.org/linux-
> > > block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
> > >
> >
> > I have only been adding the fscryp patch link as part of the cover letter - as
> a dependency.
> > https://lore.kernel.org/all/20240617005825.1443206-1-quic_gaurkash@qui
> > cinc.com/ If you would like me to include it in the patch series
> > itself, I can do that as well.
> >
> 
> I think including all prerequisite patches would be helpful for reviewers.

Noted. I'll do that for the next patch.

> 
> Thanks for continuing to work on this!
> 
> I still need to get ahold of a sm8650 based device and test this out.  Is the
> SM8650 HDK the only option, or is there a sm8650 based phone with
> upstream support yet?

There are some devices released with SM8650 (Snapdragon 8 Gen 3). Sorry, I have
not kept track of which. I know the S24s were released with that. But there should be
more in the market.

> 
> - Eric

Re: [PATCH v5 04/15] soc: qcom: ice: add hwkm support in ice

[neil.armstrong]

On 25/06/2024 06:58, Gaurav Kashyap (QUIC) wrote:
> 
> Hey Eric
> 
> On 06/21/2024, 9:02 AM PDT, Eric Biggers wrote:
>> On Fri, Jun 21, 2024 at 03:35:40PM +0000, Gaurav Kashyap wrote:
>>> Hello Eric
>>>
>>> On 06/20/2024, 9:48 PM PDT, Eric Biggers wrote:
>>>> On Thu, Jun 20, 2024 at 02:57:40PM +0300, Dmitry Baryshkov wrote:
>>>>>>>>
>>>>>>>>> Is it possible to use both kind of keys when working on
>>>>>>>>> standard
>>>> mode?
>>>>>>>>> If not, it should be the user who selects what type of
>>>>>>>>> keys to be
>>>> used.
>>>>>>>>> Enforcing this via DT is not a way to go.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately, that support is not there yet. When you say
>>>>>>>> user, do you mean to have it as a filesystem mount option?
>>>>>>>
>>>>>>> During cryptsetup time. When running e.g. cryptsetup I, as a
>>>>>>> user, would like to be able to use either a hardware-wrapped
>>>>>>> key or a
>>>> standard key.
>>>>>>>
>>>>>>
>>>>>> What we are looking for with these patches is for
>>>>>> per-file/folder
>>>> encryption using fscrypt policies.
>>>>>> Cryptsetup to my understanding supports only full-disk , and
>>>>>> does not support FBE (File-Based)
>>>>>
>>>>> I must admit, I mostly used dm-crypt beforehand, so I had to look
>>>>> at fscrypt now. Some of my previous comments might not be fully
>>>>> applicable.
>>>>>
>>>>>> Hence the idea here is that we mount an unencrypted device (with
>>>>>> the inlinecrypt option that indicates inline encryption is
>>>>>> supported) And
>>>> specify policies (links to keys) for different folders.
>>>>>>
>>>>>>>> The way the UFS/EMMC crypto layer is designed currently is
>>>>>>>> that, this information is needed when the modules are loaded.
>>>>>>>>
>>>>>>>> https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@
>>>>>>>> kern el.org /#Z31drivers:ufs:core:ufshcd-crypto.c
>>>>>>>
>>>>>>> I see that the driver lists capabilities here. E.g. that it
>>>>>>> supports HW-wrapped keys. But the line doesn't specify that
>>>>>>> standard
>>>> keys are not supported.
>>>>>>>
>>>>>>
>>>>>> Those are capabilities that are read from the storage controller.
>>>>>> However, wrapped keys Are not a standard in the ICE JEDEC
>>>>>> specification, and in most cases, is a value add coming from the SoC.
>>>>>>
>>>>>> QCOM SOC and firmware currently does not support both kinds of
>>>>>> keys in
>>>> the HWKM mode.
>>>>>> That is something we are internally working on, but not available yet.
>>>>>
>>>>> I'd say this is a significant obstacle, at least from my point of
>>>>> view. I understand that the default might be to use hw-wrapped
>>>>> keys, but it should be possible for the user to select non-HW keys
>>>>> if the ability to recover the data is considered to be important.
>>>>> Note, I'm really pointing to the user here, not to the system
>>>>> integrator. So using DT property or specifying kernel arguments to
>>>>> switch between these modes is not really an option.
>>>>>
>>>>> But I'd really love to hear some feedback from linux-security
>>>>> and/or linux-fscrypt here.
>>>>>
>>>>> In my humble opinion the user should be able to specify that the
>>>>> key is wrapped using the hardware KMK. Then if the hardware has
>>>>> already started using the other kind of keys, it should be able to
>>>>> respond with -EINVAL / whatever else. Then the user can evict
>>>>> previously programmed key and program a desired one.
>>>>>
>>>>>>> Also, I'd have expected that hw-wrapped keys are handled using
>>>>>>> trusted keys mechanism (see security/keys/trusted-keys/).
>>>>>>> Could you please point out why that's not the case?
>>>>>>>
>>>>>>
>>>>>> I will evaluate this.
>>>>>> But my initial response is that we currently cannot communicate
>>>>>> to our TPM directly from HLOS, but goes through QTEE, and I
>>>>>> don't think our qtee currently interfaces with the open source
>>>>>> tee driver. The
>>>> interface is through QCOM SCM driver.
>>>>>
>>>>> Note, this is just an API interface, see how it is implemented for
>>>>> the CAAM hardware.
>>>>>
>>>>
>>>> The problem is that this patchset was sent out without the patches
>>>> that add the block and filesystem-level framework for
>>>> hardware-wrapped inline encryption keys, which it depends on.  So
>>>> it's lacking context.  The proposed framework can be found at
>>>> https://lore.kernel.org/linux-
>>>> block/20231104211259.17448-1-ebiggers@kernel.org/T/#u
>>>>
>>>
>>> I have only been adding the fscryp patch link as part of the cover letter - as
>> a dependency.
>>> https://lore.kernel.org/all/20240617005825.1443206-1-quic_gaurkash@qui
>>> cinc.com/ If you would like me to include it in the patch series
>>> itself, I can do that as well.
>>>
>>
>> I think including all prerequisite patches would be helpful for reviewers.
> 
> Noted. I'll do that for the next patch.
> 
>>
>> Thanks for continuing to work on this!
>>
>> I still need to get ahold of a sm8650 based device and test this out.  Is the
>> SM8650 HDK the only option, or is there a sm8650 based phone with
>> upstream support yet?

Yes you should be able to buy the SM8650 HDK from lantronix:
https://www.lantronix.com/products/snapdragon-8-gen-3-mobile-hardware-development-kit/

It should be supported in v6.11

Neil

> 
> There are some devices released with SM8650 (Snapdragon 8 Gen 3). Sorry, I have
> not kept track of which. I know the S24s were released with that. But there should be
> more in the market.
> 
>>
>> - Eric