[RFC PATCH v2 0/4] Inline crypto support on DragonBoard 845c

[RFC PATCH v2 0/4] Inline crypto support on DragonBoard 845c

[Eric Biggers]

Hello,

This patchset implements UFS inline crypto support on the DragonBoard
845c, using the Qualcomm Inline Crypto Engine (ICE) that's present on
the Snapdragon 845 SoC.

This is based on top of the patchset "[PATCH v7 0/9] Inline Encryption
Support" by Satya Tangirala, which adds support for the UFS standard
inline crypto, the block layer changes needed to use inline crypto, and
support for inline crypto in fscrypt (ext4 and f2fs encryption).  Link:
https://lkml.kernel.org/r/20200221115050.238976-1-satyat@google.com

This new patchset is mostly a RFC showing hardware inline crypto working
on a publicly available development board that runs the mainline Linux
kernel.  While patches 1-2 could be applied now, patches 3-4 depend on
the main "Inline Encryption Support" patchset being merged first.

Most of the logic needed to use ICE is already handled by ufshcd-crypto
and the blk-crypto framework, which are introduced by the "Inline
Encryption Support" patchset.  Therefore, this new patchset just adds
the vendor-specific parts.  I also only implemented support for version
3 of the ICE hardware, which seems to be easier to use than older
versions; and for now I only implemented UFS support, not eMMC.

Due to these factors, I was able to greatly simplify the driver from the
vendor's original.  It seems to work fine in testing with fscrypt and
with a blk-crypto self-test I'm also working on.  But I'd appreciate
feedback from anyone who may be more familiar with this hardware as to
whether I might have missed anything important.

This patchset is also available in git at:
    Repo: https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git
    Tag: db845c-crypto-v2

Changed v1 => v2:
    - Rebased onto the v7 inline encryption patchset.
    - Account for all the recent qcom_scm changes.
    - Don't ignore errors from ->program_key().
    - Don't dereference NULL hba->vops.
    - Dropped the patch that added UFSHCD_QUIRK_BROKEN_CRYPTO, as this
      flag is now included in the main inline encryption patchset.
    - Many other cleanups.

Eric Biggers (4):
  firmware: qcom_scm: Add support for programming inline crypto keys
  arm64: dts: sdm845: add Inline Crypto Engine registers and clock
  scsi: ufs: add program_key() variant op
  scsi: ufs-qcom: add Inline Crypto Engine support

 MAINTAINERS                          |   2 +-
 arch/arm64/boot/dts/qcom/sdm845.dtsi |  13 +-
 drivers/firmware/qcom_scm.c          |  96 +++++++++++
 drivers/firmware/qcom_scm.h          |   4 +
 drivers/scsi/ufs/Kconfig             |   1 +
 drivers/scsi/ufs/Makefile            |   4 +-
 drivers/scsi/ufs/ufs-qcom-ice.c      | 245 +++++++++++++++++++++++++++
 drivers/scsi/ufs/ufs-qcom.c          |  18 +-
 drivers/scsi/ufs/ufs-qcom.h          |  27 +++
 drivers/scsi/ufs/ufshcd-crypto.c     |  34 ++--
 drivers/scsi/ufs/ufshcd.h            |   3 +
 include/linux/qcom_scm.h             |  19 +++
 12 files changed, 440 insertions(+), 26 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c

-- 
2.25.1

[RFC PATCH v2 1/4] firmware: qcom_scm: Add support for programming inline crypto keys

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Add support for the Inline Crypto Engine (ICE) key programming interface
that's needed for the ufs-qcom driver to use inline encryption on
Snapdragon SoCs.  This interface consists of two SCM calls: one to
program a key into a keyslot, and one to invalidate a keyslot.

Although the UFS specification defines a standard way to do this, on
these SoCs the Linux kernel isn't permitted to access the needed crypto
configuration registers directly; these SCM calls must be used instead.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/firmware/qcom_scm.c | 96 +++++++++++++++++++++++++++++++++++++
 drivers/firmware/qcom_scm.h |  4 ++
 include/linux/qcom_scm.h    | 19 ++++++++
 3 files changed, 119 insertions(+)

diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 059bb0fbae9e..7fb9f606250f 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -9,6 +9,7 @@
 #include <linux/dma-direct.h>
 #include <linux/dma-mapping.h>
 #include <linux/module.h>
+#include <linux/slab.h>
 #include <linux/types.h>
 #include <linux/qcom_scm.h>
 #include <linux/of.h>
@@ -926,6 +927,101 @@ int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
 }
 EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
 
+/**
+ * qcom_scm_ice_available() - Is the ICE key programming interface available?
+ *
+ * Return: true iff the SCM calls wrapped by qcom_scm_ice_invalidate_key() and
+ *	   qcom_scm_ice_set_key() are available.
+ */
+bool qcom_scm_ice_available(void)
+{
+	return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
+					    QCOM_SCM_ES_INVALIDATE_ICE_KEY) &&
+		__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
+					     QCOM_SCM_ES_CONFIG_SET_ICE_KEY);
+}
+EXPORT_SYMBOL(qcom_scm_ice_available);
+
+/**
+ * qcom_scm_ice_invalidate_key() - Invalidate an inline encryption key
+ * @index: the keyslot to invalidate
+ *
+ * The UFSHCI standard defines a standard way to do this, but it doesn't work on
+ * these SoCs; only this SCM call does.
+ *
+ * Return: 0 on success; -errno on failure.
+ */
+int qcom_scm_ice_invalidate_key(u32 index)
+{
+	struct qcom_scm_desc desc = {
+		.svc = QCOM_SCM_SVC_ES,
+		.cmd = QCOM_SCM_ES_INVALIDATE_ICE_KEY,
+		.arginfo = QCOM_SCM_ARGS(1),
+		.args[0] = index,
+		.owner = ARM_SMCCC_OWNER_SIP,
+	};
+
+	return qcom_scm_call(__scm->dev, &desc, NULL);
+}
+EXPORT_SYMBOL(qcom_scm_ice_invalidate_key);
+
+/**
+ * qcom_scm_ice_set_key() - Set an inline encryption key
+ * @index: the keyslot into which to set the key
+ * @key: the key to program
+ * @key_size: the size of the key in bytes
+ * @cipher: the encryption algorithm the key is for
+ * @data_unit_size: the encryption data unit size, i.e. the size of each
+ *		    individual plaintext and ciphertext.  Given in 512-byte
+ *		    units, e.g. 1 = 512 bytes, 8 = 4096 bytes, etc.
+ *
+ * Program a key into a keyslot of Qualcomm ICE (Inline Crypto Engine), where it
+ * can then be used to encrypt/decrypt UFS I/O requests inline.
+ *
+ * The UFSHCI standard defines a standard way to do this, but it doesn't work on
+ * these SoCs; only this SCM call does.
+ *
+ * Return: 0 on success; -errno on failure.
+ */
+int qcom_scm_ice_set_key(u32 index, const u8 *key, int key_size,
+			 enum qcom_scm_ice_cipher cipher, int data_unit_size)
+{
+	struct qcom_scm_desc desc = {
+		.svc = QCOM_SCM_SVC_ES,
+		.cmd = QCOM_SCM_ES_CONFIG_SET_ICE_KEY,
+		.arginfo = QCOM_SCM_ARGS(5, QCOM_SCM_VAL, QCOM_SCM_RW,
+					 QCOM_SCM_VAL, QCOM_SCM_VAL,
+					 QCOM_SCM_VAL),
+		.args[0] = index,
+		.args[2] = key_size,
+		.args[3] = cipher,
+		.args[4] = data_unit_size,
+		.owner = ARM_SMCCC_OWNER_SIP,
+	};
+	u8 *keybuf;
+	dma_addr_t key_phys;
+	int ret;
+
+	keybuf = kmemdup(key, key_size, GFP_KERNEL);
+	if (!keybuf)
+		return -ENOMEM;
+
+	key_phys = dma_map_single(__scm->dev, keybuf, key_size, DMA_TO_DEVICE);
+	if (dma_mapping_error(__scm->dev, key_phys)) {
+		ret = -ENOMEM;
+		goto out;
+	}
+	desc.args[1] = key_phys;
+
+	ret = qcom_scm_call(__scm->dev, &desc, NULL);
+
+	dma_unmap_single(__scm->dev, key_phys, key_size, DMA_TO_DEVICE);
+out:
+	kzfree(keybuf);
+	return ret;
+}
+EXPORT_SYMBOL(qcom_scm_ice_set_key);
+
 /**
  * qcom_scm_hdcp_available() - Check if secure environment supports HDCP.
  *
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index d9ed670da222..38ea614d29fe 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -103,6 +103,10 @@ extern int scm_legacy_call(struct device *dev, const struct qcom_scm_desc *desc,
 #define QCOM_SCM_OCMEM_LOCK_CMD		0x01
 #define QCOM_SCM_OCMEM_UNLOCK_CMD	0x02
 
+#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_SVC_HDCP		0x11
 #define QCOM_SCM_HDCP_INVOKE		0x01
 
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 3d6a24697761..8ca90f192aeb 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -44,6 +44,13 @@ enum qcom_scm_sec_dev_id {
 	QCOM_SCM_ICE_DEV_ID     = 20,
 };
 
+enum qcom_scm_ice_cipher {
+	QCOM_SCM_ICE_CIPHER_AES_128_XTS = 0,
+	QCOM_SCM_ICE_CIPHER_AES_128_CBC = 1,
+	QCOM_SCM_ICE_CIPHER_AES_256_XTS = 3,
+	QCOM_SCM_ICE_CIPHER_AES_256_CBC = 4,
+};
+
 #define QCOM_SCM_VMID_HLOS       0x3
 #define QCOM_SCM_VMID_MSS_MSA    0xF
 #define QCOM_SCM_VMID_WLAN       0x18
@@ -88,6 +95,12 @@ extern int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset,
 extern int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset,
 				 u32 size);
 
+extern bool qcom_scm_ice_available(void);
+extern int qcom_scm_ice_invalidate_key(u32 index);
+extern int qcom_scm_ice_set_key(u32 index, const u8 *key, int key_size,
+				enum qcom_scm_ice_cipher cipher,
+				int data_unit_size);
+
 extern bool qcom_scm_hdcp_available(void);
 extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
 			     u32 *resp);
@@ -138,6 +151,12 @@ static inline int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset,
 static inline int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id,
 		u32 offset, u32 size) { return -ENODEV; }
 
+static inline bool qcom_scm_ice_available(void) { return false; }
+static inline int qcom_scm_ice_invalidate_key(u32 index) { return -ENODEV; }
+static inline int qcom_scm_ice_set_key(u32 index, const u8 *key, int key_size,
+				       enum qcom_scm_ice_cipher cipher,
+				       int data_unit_size) { return -ENODEV; }
+
 static inline bool qcom_scm_hdcp_available(void) { return false; }
 static inline int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
 		u32 *resp) { return -ENODEV; }
-- 
2.25.1

[RFC PATCH v2 2/4] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Add the vendor-specific registers and clock for Qualcomm ICE (Inline
Crypto Engine) to the device tree node for the UFS host controller on
sdm845, so that the ufs-qcom driver will be able to use inline crypto.

Use a separate register range rather than extending the main UFS range
because there's a gap between the two, and the ICE registers are
vendor-specific.  (Actually, the hardware claims that the ICE range also
includes the array of standard crypto configuration registers; however,
on this SoC the Linux kernel isn't permitted to access them directly.)

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index d42302b8889b..dd6b4e596fcf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1367,7 +1367,9 @@ system-cache-controller@1100000 {
 		ufs_mem_hc: ufshc@1d84000 {
 			compatible = "qcom,sdm845-ufshc", "qcom,ufshc",
 				     "jedec,ufs-2.0";
-			reg = <0 0x01d84000 0 0x2500>;
+			reg = <0 0x01d84000 0 0x2500>,
+			      <0 0 0 0>,
+			      <0 0x01d90000 0 0x8000>;
 			interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
 			phys = <&ufs_mem_phy_lanes>;
 			phy-names = "ufsphy";
@@ -1387,7 +1389,8 @@ ufs_mem_hc: ufshc@1d84000 {
 				"ref_clk",
 				"tx_lane0_sync_clk",
 				"rx_lane0_sync_clk",
-				"rx_lane1_sync_clk";
+				"rx_lane1_sync_clk",
+				"ice_core_clk";
 			clocks =
 				<&gcc GCC_UFS_PHY_AXI_CLK>,
 				<&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
@@ -1396,7 +1399,8 @@ ufs_mem_hc: ufshc@1d84000 {
 				<&rpmhcc RPMH_CXO_CLK>,
 				<&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
 				<&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
-				<&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
+				<&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>,
+				<&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
 			freq-table-hz =
 				<50000000 200000000>,
 				<0 0>,
@@ -1405,7 +1409,8 @@ ufs_mem_hc: ufshc@1d84000 {
 				<0 0>,
 				<0 0>,
 				<0 0>,
-				<0 0>;
+				<0 0>,
+				<0 300000000>;
 
 			status = "disabled";
 		};
-- 
2.25.1

[RFC PATCH v2 3/4] scsi: ufs: add program_key() variant op

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

On Snapdragon SoCs, the Linux kernel isn't permitted to directly access
the standard UFS crypto configuration registers.  Instead, programming
and evicting keys must be done through vendor-specific SMC calls.

To support this hardware, add a ->program_key() method to
'struct ufs_hba_variant_ops'.  This allows overriding the UFS standard
key programming / eviction procedure.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/scsi/ufs/ufshcd-crypto.c | 34 +++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h        |  3 +++
 2 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
index cd7ca50a1dd9..7c50d1d4f58c 100644
--- a/drivers/scsi/ufs/ufshcd-crypto.c
+++ b/drivers/scsi/ufs/ufshcd-crypto.c
@@ -131,14 +131,20 @@ static int ufshcd_crypto_cfg_entry_write_key(union ufs_crypto_cfg_entry *cfg,
 	return -EINVAL;
 }
 
-static void ufshcd_program_key(struct ufs_hba *hba,
-			       const union ufs_crypto_cfg_entry *cfg,
-			       int slot)
+static int ufshcd_program_key(struct ufs_hba *hba,
+			      const union ufs_crypto_cfg_entry *cfg, int slot)
 {
 	int i;
 	u32 slot_offset = hba->crypto_cfg_register + slot * sizeof(*cfg);
+	int err = 0;
 
 	ufshcd_hold(hba, false);
+
+	if (hba->vops && hba->vops->program_key) {
+		err = hba->vops->program_key(hba, cfg, slot);
+		goto out;
+	}
+
 	/* Ensure that CFGE is cleared before programming the key */
 	ufshcd_writel(hba, 0, slot_offset + 16 * sizeof(cfg->reg_val[0]));
 	for (i = 0; i < 16; i++) {
@@ -151,23 +157,28 @@ static void ufshcd_program_key(struct ufs_hba *hba,
 	/* Dword 16 must be written last */
 	ufshcd_writel(hba, le32_to_cpu(cfg->reg_val[16]),
 		      slot_offset + 16 * sizeof(cfg->reg_val[0]));
+out:
 	ufshcd_release(hba);
+	return err;
 }
 
-static void ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
+static int ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
 {
 	union ufs_crypto_cfg_entry cfg = { 0 };
 
-	ufshcd_program_key(hba, &cfg, slot);
+	return ufshcd_program_key(hba, &cfg, slot);
 }
 
 /* Clear all keyslots at driver init time */
 static void ufshcd_clear_all_keyslots(struct ufs_hba *hba)
 {
 	int slot;
+	int err;
 
-	for (slot = 0; slot < ufshcd_num_keyslots(hba); slot++)
-		ufshcd_clear_keyslot(hba, slot);
+	for (slot = 0; slot < ufshcd_num_keyslots(hba); slot++) {
+		err = ufshcd_clear_keyslot(hba, slot);
+		WARN_ON_ONCE(err);
+	}
 }
 
 static int ufshcd_crypto_keyslot_program(struct keyslot_manager *ksm,
@@ -203,10 +214,11 @@ static int ufshcd_crypto_keyslot_program(struct keyslot_manager *ksm,
 	if (err)
 		return err;
 
-	ufshcd_program_key(hba, &cfg, slot);
+	err = ufshcd_program_key(hba, &cfg, slot);
 
 	memzero_explicit(&cfg, sizeof(cfg));
-	return 0;
+
+	return err;
 }
 
 static int ufshcd_crypto_keyslot_evict(struct keyslot_manager *ksm,
@@ -223,9 +235,7 @@ static int ufshcd_crypto_keyslot_evict(struct keyslot_manager *ksm,
 	 * Clear the crypto cfg on the device. Clearing CFGE
 	 * might not be sufficient, so just clear the entire cfg.
 	 */
-	ufshcd_clear_keyslot(hba, slot);
-
-	return 0;
+	return ufshcd_clear_keyslot(hba, slot);
 }
 
 void ufshcd_crypto_enable(struct ufs_hba *hba)
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index c8f948aa5e3d..c2656575e24b 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -306,6 +306,7 @@ struct ufs_pwr_mode_info {
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
  * @device_reset: called to issue a reset pulse on the UFS device
+ * @program_key: program or evict an inline encryption key
  */
 struct ufs_hba_variant_ops {
 	const char *name;
@@ -335,6 +336,8 @@ struct ufs_hba_variant_ops {
 	void	(*dbg_register_dump)(struct ufs_hba *hba);
 	int	(*phy_initialization)(struct ufs_hba *);
 	void	(*device_reset)(struct ufs_hba *hba);
+	int	(*program_key)(struct ufs_hba *hba,
+			       const union ufs_crypto_cfg_entry *cfg, int slot);
 };
 
 /* clock gating state  */
-- 
2.25.1

[RFC PATCH v2 4/4] scsi: ufs-qcom: add Inline Crypto Engine support

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.

The standards-compliant parts, such as querying the crypto capabilities
and enabling crypto for individual UFS requests, are already handled by
ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
However, ICE requires vendor-specific init, enable, and resume logic,
and it requires that keys be programmed and evicted by vendor-specific
SMC calls.  Make the ufs-qcom driver handle these details.

I tested this on Dragonboard 845c, which is a publicly available
development board that uses the Snapdragon 845 SoC.  This is the same
SoC used in the Pixel 3 and Pixel 3 XL phones.  This testing included
(among other things) verifying that the expected ciphertext was produced
for the key and IV used, both manually using ext4 encryption and
automatically using a block layer self-test I've written.

This is based very loosely on the vendor-provided driver in the kernel
source code for the Pixel 3, but I've greatly simplified it.  Also, for
now I've only included support for major version 3 of ICE, since that's
all I have the hardware to test with the mainline kernel.  Plus it
appears that version 3 is easier to use than older versions of ICE.

For now, only allow using AES-256-XTS.  The hardware also declares
support for AES-128-XTS, AES-{128,256}-ECB, and AES-{128,256}-CBC
(BitLocker variant).  But none of these others are really useful, and
they'd need to be individually tested to be sure they worked properly.

This commit also changes the name of the loadable module from "ufs-qcom"
to "ufs_qcom", as this is necessary to compile it from multiple source
files (unless we were to rename ufs-qcom.c).

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 MAINTAINERS                     |   2 +-
 drivers/scsi/ufs/Kconfig        |   1 +
 drivers/scsi/ufs/Makefile       |   4 +-
 drivers/scsi/ufs/ufs-qcom-ice.c | 244 ++++++++++++++++++++++++++++++++
 drivers/scsi/ufs/ufs-qcom.c     |  18 +--
 drivers/scsi/ufs/ufs-qcom.h     |  27 ++++
 6 files changed, 286 insertions(+), 10 deletions(-)
 create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a0d86490c2c6..d0df7738fcb8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2202,7 +2202,7 @@ F:	drivers/pci/controller/dwc/pcie-qcom.c
 F:	drivers/phy/qualcomm/
 F:	drivers/power/*/msm*
 F:	drivers/reset/reset-qcom-*
-F:	drivers/scsi/ufs/ufs-qcom.*
+F:	drivers/scsi/ufs/ufs-qcom*
 F:	drivers/spi/spi-qup.c
 F:	drivers/spi/spi-geni-qcom.c
 F:	drivers/spi/spi-qcom-qspi.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index c69f1b49167b..7d1260988ab2 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -99,6 +99,7 @@ config SCSI_UFS_DWC_TC_PLATFORM
 config SCSI_UFS_QCOM
 	tristate "QCOM specific hooks to UFS controller platform driver"
 	depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
+	select QCOM_SCM
 	select RESET_CONTROLLER
 	help
 	  This selects the QCOM specific additions to UFSHCD platform driver.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 197e178f44bc..13fda1b697b2 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -3,7 +3,9 @@
 obj-$(CONFIG_SCSI_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o tc-dwc-g210.o
 obj-$(CONFIG_SCSI_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o tc-dwc-g210.o
 obj-$(CONFIG_SCSI_UFS_CDNS_PLATFORM) += cdns-pltfrm.o
-obj-$(CONFIG_SCSI_UFS_QCOM) += ufs-qcom.o
+obj-$(CONFIG_SCSI_UFS_QCOM) += ufs_qcom.o
+ufs_qcom-y += ufs-qcom.o
+ufs_qcom-$(CONFIG_SCSI_UFS_CRYPTO) += ufs-qcom-ice.o
 obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
 ufshcd-core-y				+= ufshcd.o ufs-sysfs.o
 ufshcd-core-$(CONFIG_SCSI_UFS_BSG)	+= ufs_bsg.o
diff --git a/drivers/scsi/ufs/ufs-qcom-ice.c b/drivers/scsi/ufs/ufs-qcom-ice.c
new file mode 100644
index 000000000000..808c5dda019e
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-qcom-ice.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm ICE (Inline Crypto Engine) support.
+ *
+ * Copyright (c) 2014-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019 Google LLC
+ */
+
+#include <linux/platform_device.h>
+#include <linux/qcom_scm.h>
+
+#include "ufshcd-crypto.h"
+#include "ufs-qcom.h"
+
+#define AES_256_XTS_KEY_SIZE			64
+
+/* QCOM ICE registers */
+
+#define QCOM_ICE_REG_CONTROL			0x0000
+#define QCOM_ICE_REG_RESET			0x0004
+#define QCOM_ICE_REG_VERSION			0x0008
+#define QCOM_ICE_REG_FUSE_SETTING		0x0010
+#define QCOM_ICE_REG_PARAMETERS_1		0x0014
+#define QCOM_ICE_REG_PARAMETERS_2		0x0018
+#define QCOM_ICE_REG_PARAMETERS_3		0x001C
+#define QCOM_ICE_REG_PARAMETERS_4		0x0020
+#define QCOM_ICE_REG_PARAMETERS_5		0x0024
+
+/* QCOM ICE v3.X only */
+#define QCOM_ICE_GENERAL_ERR_STTS		0x0040
+#define QCOM_ICE_INVALID_CCFG_ERR_STTS		0x0030
+#define QCOM_ICE_GENERAL_ERR_MASK		0x0044
+
+/* QCOM ICE v2.X only */
+#define QCOM_ICE_REG_NON_SEC_IRQ_STTS		0x0040
+#define QCOM_ICE_REG_NON_SEC_IRQ_MASK		0x0044
+
+#define QCOM_ICE_REG_NON_SEC_IRQ_CLR		0x0048
+#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME1	0x0050
+#define QCOM_ICE_REG_STREAM1_ERROR_SYNDROME2	0x0054
+#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME1	0x0058
+#define QCOM_ICE_REG_STREAM2_ERROR_SYNDROME2	0x005C
+#define QCOM_ICE_REG_STREAM1_BIST_ERROR_VEC	0x0060
+#define QCOM_ICE_REG_STREAM2_BIST_ERROR_VEC	0x0064
+#define QCOM_ICE_REG_STREAM1_BIST_FINISH_VEC	0x0068
+#define QCOM_ICE_REG_STREAM2_BIST_FINISH_VEC	0x006C
+#define QCOM_ICE_REG_BIST_STATUS		0x0070
+#define QCOM_ICE_REG_BYPASS_STATUS		0x0074
+#define QCOM_ICE_REG_ADVANCED_CONTROL		0x1000
+#define QCOM_ICE_REG_ENDIAN_SWAP		0x1004
+#define QCOM_ICE_REG_TEST_BUS_CONTROL		0x1010
+#define QCOM_ICE_REG_TEST_BUS_REG		0x1014
+
+/* BIST ("built-in self-test"?) status flags */
+#define QCOM_ICE_BIST_STATUS_MASK		0xF0000000
+
+#define QCOM_ICE_FUSE_SETTING_MASK		0x1
+#define QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK	0x2
+#define QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK	0x4
+
+#define qcom_ice_writel(host, val, reg)	\
+	writel((val), (host)->ice_mmio + (reg))
+#define qcom_ice_readl(host, reg)	\
+	readl((host)->ice_mmio + (reg))
+
+static bool qcom_ice_supported(struct ufs_qcom_host *host)
+{
+	struct device *dev = host->hba->dev;
+	u32 regval = qcom_ice_readl(host, QCOM_ICE_REG_VERSION);
+	int major = regval >> 24;
+	int minor = (regval >> 16) & 0xFF;
+	int step = regval & 0xFFFF;
+
+	/* For now this driver only supports ICE version 3. */
+	if (major != 3) {
+		dev_warn(dev, "Unsupported ICE version: v%d.%d.%d\n",
+			 major, minor, step);
+		return false;
+	}
+
+	dev_info(dev, "Found QC Inline Crypto Engine (ICE) v%d.%d.%d\n",
+		 major, minor, step);
+
+	/* If fuses are blown, ICE might not work in the standard way. */
+	regval = qcom_ice_readl(host, QCOM_ICE_REG_FUSE_SETTING);
+	if (regval & (QCOM_ICE_FUSE_SETTING_MASK |
+		      QCOM_ICE_FORCE_HW_KEY0_SETTING_MASK |
+		      QCOM_ICE_FORCE_HW_KEY1_SETTING_MASK)) {
+		dev_warn(dev, "Fuses are blown; ICE is unusable!\n");
+		return false;
+	}
+	return true;
+}
+
+int ufs_qcom_ice_init(struct ufs_qcom_host *host)
+{
+	struct ufs_hba *hba = host->hba;
+	struct device *dev = hba->dev;
+	struct platform_device *pdev = to_platform_device(dev);
+	struct resource *res;
+	int err;
+
+	if (!(ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES) &
+	      MASK_CRYPTO_SUPPORT))
+		return 0;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+	if (!res) {
+		dev_warn(dev, "ICE registers not found\n");
+		goto disable;
+	}
+
+	if (!qcom_scm_ice_available()) {
+		dev_warn(dev, "ICE SCM interface not found\n");
+		goto disable;
+	}
+
+	host->ice_mmio = devm_ioremap_resource(dev, res);
+	if (IS_ERR(host->ice_mmio)) {
+		dev_err(dev, "Failed to map ICE registers; err=%d\n", err);
+		return err;
+	}
+
+	if (!qcom_ice_supported(host))
+		goto disable;
+
+	return 0;
+
+disable:
+	dev_warn(dev, "Disabling inline encryption support\n");
+	hba->quirks |= UFSHCD_QUIRK_BROKEN_CRYPTO;
+	return 0;
+}
+
+static void qcom_ice_low_power_mode_enable(struct ufs_qcom_host *host)
+{
+	u32 regval;
+
+	regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
+	/*
+	 * Enable low power mode sequence
+	 * [0]-0, [1]-0, [2]-0, [3]-E, [4]-0, [5]-0, [6]-0, [7]-0
+	 */
+	regval |= 0x7000;
+	qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
+}
+
+static void qcom_ice_optimization_enable(struct ufs_qcom_host *host)
+{
+	u32 regval;
+
+	/* ICE Optimizations Enable Sequence */
+	regval = qcom_ice_readl(host, QCOM_ICE_REG_ADVANCED_CONTROL);
+	regval |= 0xD807100;
+	/* ICE HPG requires delay before writing */
+	udelay(5);
+	qcom_ice_writel(host, regval, QCOM_ICE_REG_ADVANCED_CONTROL);
+	udelay(5);
+}
+
+int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
+{
+	if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
+		return 0;
+	qcom_ice_low_power_mode_enable(host);
+	qcom_ice_optimization_enable(host);
+	return ufs_qcom_ice_resume(host);
+}
+
+/* Poll until all BIST bits are reset */
+static int qcom_ice_wait_bist_status(struct ufs_qcom_host *host)
+{
+	int count;
+	u32 reg;
+
+	for (count = 0; count < 100; count++) {
+		reg = qcom_ice_readl(host, QCOM_ICE_REG_BIST_STATUS);
+		if (!(reg & QCOM_ICE_BIST_STATUS_MASK))
+			break;
+		udelay(50);
+	}
+	if (reg)
+		return -ETIMEDOUT;
+	return 0;
+}
+
+int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
+{
+	int err;
+
+	if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
+		return 0;
+
+	err = qcom_ice_wait_bist_status(host);
+	if (err) {
+		dev_err(host->hba->dev, "BIST status error (%d)\n", err);
+		return err;
+	}
+	return 0;
+}
+
+/*
+ * Program a key into a QC ICE keyslot, or evict a keyslot.  QC ICE requires
+ * vendor-specific SCM calls for this; it doesn't support the standard way.
+ */
+int ufs_qcom_ice_program_key(struct ufs_hba *hba,
+			     const union ufs_crypto_cfg_entry *cfg, int slot)
+{
+	union ufs_crypto_cap_entry cap;
+	union {
+		u8 bytes[AES_256_XTS_KEY_SIZE];
+		u32 words[AES_256_XTS_KEY_SIZE / sizeof(u32)];
+	} key;
+	int i;
+	int err;
+
+	if (!(cfg->config_enable & UFS_CRYPTO_CONFIGURATION_ENABLE))
+		return qcom_scm_ice_invalidate_key(slot);
+
+	/* Only AES-256-XTS has been tested so far. */
+	cap = hba->crypto_cap_array[cfg->crypto_cap_idx];
+	if (cap.algorithm_id != UFS_CRYPTO_ALG_AES_XTS ||
+	    cap.key_size != UFS_CRYPTO_KEY_SIZE_256) {
+		dev_err_ratelimited(hba->dev,
+				    "Unhandled crypto capability; algorithm_id=%d, key_size=%d\n",
+				    cap.algorithm_id, cap.key_size);
+		return -EINVAL;
+	}
+
+	memcpy(key.bytes, cfg->crypto_key, AES_256_XTS_KEY_SIZE);
+
+	/*
+	 * ICE (or maybe the SCM call?) byte-swaps the 32-bit words of the key.
+	 * So we have to do the same, in order for the final key be correct.
+	 */
+	for (i = 0; i < ARRAY_SIZE(key.words); i++)
+		__cpu_to_be32s(&key.words[i]);
+
+	err = qcom_scm_ice_set_key(slot, key.bytes, AES_256_XTS_KEY_SIZE,
+				   QCOM_SCM_ICE_CIPHER_AES_256_XTS,
+				   cfg->data_unit_size);
+	memzero_explicit(&key, sizeof(key));
+	return err;
+}
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 4b2ec3745a16..b626ed834a67 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -365,7 +365,7 @@ static int ufs_qcom_hce_enable_notify(struct ufs_hba *hba,
 		/* check if UFS PHY moved from DISABLED to HIBERN8 */
 		err = ufs_qcom_check_hibern8(hba);
 		ufs_qcom_enable_hw_clk_gating(hba);
-
+		ufs_qcom_ice_enable(host);
 		break;
 	default:
 		dev_err(hba->dev, "%s: invalid status %d\n", __func__, status);
@@ -616,6 +616,10 @@ static int ufs_qcom_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
 			return err;
 	}
 
+	err = ufs_qcom_ice_resume(host);
+	if (err)
+		return err;
+
 	hba->is_sys_suspended = false;
 	return 0;
 }
@@ -1002,13 +1006,6 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
 				| UFSHCD_QUIRK_DME_PEER_ACCESS_AUTO_MODE
 				| UFSHCD_QUIRK_BROKEN_PA_RXHSUNTERMCAP);
 	}
-
-	/*
-	 * Inline crypto is currently broken with ufs-qcom at least because the
-	 * device tree doesn't include the crypto registers.  There are likely
-	 * to be other issues that will need to be addressed too.
-	 */
-	hba->quirks |= UFSHCD_QUIRK_BROKEN_CRYPTO;
 }
 
 static void ufs_qcom_set_caps(struct ufs_hba *hba)
@@ -1245,6 +1242,10 @@ static int ufs_qcom_init(struct ufs_hba *hba)
 	ufs_qcom_set_caps(hba);
 	ufs_qcom_advertise_quirks(hba);
 
+	err = ufs_qcom_ice_init(host);
+	if (err)
+		goto out_variant_clear;
+
 	ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
 
 	if (hba->dev->id < MAX_UFS_QCOM_HOSTS)
@@ -1658,6 +1659,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
 	.resume			= ufs_qcom_resume,
 	.dbg_register_dump	= ufs_qcom_dump_dbg_regs,
 	.device_reset		= ufs_qcom_device_reset,
+	.program_key		= ufs_qcom_ice_program_key,
 };
 
 /**
diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
index 2d95e7cc7187..97247d17e258 100644
--- a/drivers/scsi/ufs/ufs-qcom.h
+++ b/drivers/scsi/ufs/ufs-qcom.h
@@ -227,6 +227,9 @@ struct ufs_qcom_host {
 	void __iomem *dev_ref_clk_ctrl_mmio;
 	bool is_dev_ref_clk_enabled;
 	struct ufs_hw_version hw_ver;
+#ifdef CONFIG_SCSI_UFS_CRYPTO
+	void __iomem *ice_mmio;
+#endif
 
 	u32 dev_ref_clk_en_mask;
 
@@ -264,4 +267,28 @@ static inline bool ufs_qcom_cap_qunipro(struct ufs_qcom_host *host)
 		return false;
 }
 
+/* ufs-qcom-ice.c */
+
+#ifdef CONFIG_SCSI_UFS_CRYPTO
+int ufs_qcom_ice_init(struct ufs_qcom_host *host);
+int ufs_qcom_ice_enable(struct ufs_qcom_host *host);
+int ufs_qcom_ice_resume(struct ufs_qcom_host *host);
+int ufs_qcom_ice_program_key(struct ufs_hba *hba,
+			     const union ufs_crypto_cfg_entry *cfg, int slot);
+#else
+static inline int ufs_qcom_ice_init(struct ufs_qcom_host *host)
+{
+	return 0;
+}
+static inline int ufs_qcom_ice_enable(struct ufs_qcom_host *host)
+{
+	return 0;
+}
+static inline int ufs_qcom_ice_resume(struct ufs_qcom_host *host)
+{
+	return 0;
+}
+#define ufs_qcom_ice_program_key NULL
+#endif /* !CONFIG_SCSI_UFS_CRYPTO */
+
 #endif /* UFS_QCOM_H_ */
-- 
2.25.1

Re: [RFC PATCH v2 1/4] firmware: qcom_scm: Add support for programming inline crypto keys

[Stephen Boyd]

Quoting Eric Biggers (2020-03-03 22:49:39)
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 059bb0fbae9e..7fb9f606250f 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -926,6 +927,101 @@ int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
[...]
> +
> +/**
> + * qcom_scm_ice_set_key() - Set an inline encryption key
> + * @index: the keyslot into which to set the key
> + * @key: the key to program
> + * @key_size: the size of the key in bytes
> + * @cipher: the encryption algorithm the key is for
> + * @data_unit_size: the encryption data unit size, i.e. the size of each
> + *                 individual plaintext and ciphertext.  Given in 512-byte
> + *                 units, e.g. 1 = 512 bytes, 8 = 4096 bytes, etc.
> + *
> + * Program a key into a keyslot of Qualcomm ICE (Inline Crypto Engine), where it
> + * can then be used to encrypt/decrypt UFS I/O requests inline.
> + *
> + * The UFSHCI standard defines a standard way to do this, but it doesn't work on
> + * these SoCs; only this SCM call does.
> + *
> + * Return: 0 on success; -errno on failure.
> + */
> +int qcom_scm_ice_set_key(u32 index, const u8 *key, int key_size,
> +                        enum qcom_scm_ice_cipher cipher, int data_unit_size)

Why not make key_size and data_unit_size unsigned?

> +{
> +       struct qcom_scm_desc desc = {
> +               .svc = QCOM_SCM_SVC_ES,
> +               .cmd = QCOM_SCM_ES_CONFIG_SET_ICE_KEY,
> +               .arginfo = QCOM_SCM_ARGS(5, QCOM_SCM_VAL, QCOM_SCM_RW,
> +                                        QCOM_SCM_VAL, QCOM_SCM_VAL,
> +                                        QCOM_SCM_VAL),
> +               .args[0] = index,
> +               .args[2] = key_size,
> +               .args[3] = cipher,
> +               .args[4] = data_unit_size,
> +               .owner = ARM_SMCCC_OWNER_SIP,
> +       };
> +       u8 *keybuf;
> +       dma_addr_t key_phys;
> +       int ret;
> +
> +       keybuf = kmemdup(key, key_size, GFP_KERNEL);

Is this to make the key physically contiguous? Probably worth a comment
to help others understand why this is here.

> +       if (!keybuf)
> +               return -ENOMEM;
> +
> +       key_phys = dma_map_single(__scm->dev, keybuf, key_size, DMA_TO_DEVICE);
> +       if (dma_mapping_error(__scm->dev, key_phys)) {
> +               ret = -ENOMEM;
> +               goto out;
> +       }
> +       desc.args[1] = key_phys;
> +
> +       ret = qcom_scm_call(__scm->dev, &desc, NULL);
> +
> +       dma_unmap_single(__scm->dev, key_phys, key_size, DMA_TO_DEVICE);
> +out:
> +       kzfree(keybuf);

And this is because we want to clear key contents out of the slab? What
about if the dma_map_single() bounces to a bounce buffer? I think that
isn't going to happen because __scm->dev is just some firmware device
that doesn't require bounce buffers but it's worth another comment to
clarify this.

> +       return ret;
> +}
> +EXPORT_SYMBOL(qcom_scm_ice_set_key);
> +
>  /**
>   * qcom_scm_hdcp_available() - Check if secure environment supports HDCP.
>   *

Re: [RFC PATCH v2 2/4] arm64: dts: sdm845: add Inline Crypto Engine registers and clock

[Stephen Boyd]

Quoting Eric Biggers (2020-03-03 22:49:40)
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index d42302b8889b..dd6b4e596fcf 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1367,7 +1367,9 @@ system-cache-controller@1100000 {
>                 ufs_mem_hc: ufshc@1d84000 {
>                         compatible = "qcom,sdm845-ufshc", "qcom,ufshc",
>                                      "jedec,ufs-2.0";
> -                       reg = <0 0x01d84000 0 0x2500>;
> +                       reg = <0 0x01d84000 0 0x2500>,
> +                             <0 0 0 0>,
> +                             <0 0x01d90000 0 0x8000>;

Nothing against this patch but the binding for ufs is really awful. It
doesn't indicate what the order of registers are, doesn't list what clks
are supposed to be there, has weird microamp properties that make no
sense, and has a freq-table-hz property that is almost always full of
zeroes because the driver is written in some weird qcom specific way.

It would be great to fix this binding and convert it to YAML so that we
can drop the cruft and clearly describe why this patch needs to
introduce a reg property that is all zeroes.

>                         interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>;
>                         phys = <&ufs_mem_phy_lanes>;
>                         phy-names = "ufsphy";
> @@ -1387,7 +1389,8 @@ ufs_mem_hc: ufshc@1d84000 {
>                                 "ref_clk",
>                                 "tx_lane0_sync_clk",
>                                 "rx_lane0_sync_clk",
> -                               "rx_lane1_sync_clk";
> +                               "rx_lane1_sync_clk",
> +                               "ice_core_clk";

Would be great to drop _clk postfix on all of these.

>                         clocks =
>                                 <&gcc GCC_UFS_PHY_AXI_CLK>,
>                                 <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>,
> @@ -1396,7 +1399,8 @@ ufs_mem_hc: ufshc@1d84000 {
>                                 <&rpmhcc RPMH_CXO_CLK>,
>                                 <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
>                                 <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
> -                               <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
> +                               <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>,
> +                               <&gcc GCC_UFS_PHY_ICE_CORE_CLK>;
>                         freq-table-hz =
>                                 <50000000 200000000>,
>                                 <0 0>,
> @@ -1405,7 +1409,8 @@ ufs_mem_hc: ufshc@1d84000 {
>                                 <0 0>,
>                                 <0 0>,
>                                 <0 0>,
> -                               <0 0>;
> +                               <0 0>,
> +                               <0 300000000>;

This can probably be done with assigned-clock-rates, but the driver is
bad.

RE: [RFC PATCH v2 3/4] scsi: ufs: add program_key() variant op

[bmuthuku]

Eric, I strongly recommend not to support the old mechanism of calling into
TEE to set keys as this has been deprecated and will not work with newer
hardware. There are few issues with this patch, it adds all the code within
UFS and we would have to reimplement all the common ICE code for eMMC as
well. For clearing a key, the patch uses program_key to set zeroes to the
keyslot, without going into details (since newer hardware is not yet public)
this will not work.

We have a plan to upstream ICE support with the new hardware along with the
framework to support wrapped keys and add sdhci/cqhci-crypto support.

-----Original Message-----
From: linux-fscrypt-owner@vger.kernel.org
<linux-fscrypt-owner@vger.kernel.org> On Behalf Of Eric Biggers
Sent: Tuesday, March 3, 2020 10:50 PM
To: linux-scsi@vger.kernel.org; linux-arm-msm@vger.kernel.org
Cc: linux-block@vger.kernel.org; linux-fscrypt@vger.kernel.org; Alim Akhtar
<alim.akhtar@samsung.com>; Andy Gross <agross@kernel.org>; Avri Altman
<avri.altman@wdc.com>; Barani Muthukumaran <bmuthuku@qti.qualcomm.com>;
Bjorn Andersson <bjorn.andersson@linaro.org>; Can Guo <cang@codeaurora.org>;
Elliot Berman <eberman@codeaurora.org>; Jaegeuk Kim <jaegeuk@kernel.org>
Subject: [RFC PATCH v2 3/4] scsi: ufs: add program_key() variant op

From: Eric Biggers <ebiggers@google.com>

On Snapdragon SoCs, the Linux kernel isn't permitted to directly access the
standard UFS crypto configuration registers.  Instead, programming and
evicting keys must be done through vendor-specific SMC calls.

To support this hardware, add a ->program_key() method to 'struct
ufs_hba_variant_ops'.  This allows overriding the UFS standard key
programming / eviction procedure.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 drivers/scsi/ufs/ufshcd-crypto.c | 34 +++++++++++++++++++++-----------
 drivers/scsi/ufs/ufshcd.h        |  3 +++
 2 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-crypto.c
b/drivers/scsi/ufs/ufshcd-crypto.c
index cd7ca50a1dd9..7c50d1d4f58c 100644
--- a/drivers/scsi/ufs/ufshcd-crypto.c
+++ b/drivers/scsi/ufs/ufshcd-crypto.c
@@ -131,14 +131,20 @@ static int ufshcd_crypto_cfg_entry_write_key(union
ufs_crypto_cfg_entry *cfg,
 	return -EINVAL;
 }
 
-static void ufshcd_program_key(struct ufs_hba *hba,
-			       const union ufs_crypto_cfg_entry *cfg,
-			       int slot)
+static int ufshcd_program_key(struct ufs_hba *hba,
+			      const union ufs_crypto_cfg_entry *cfg, int
slot)
 {
 	int i;
 	u32 slot_offset = hba->crypto_cfg_register + slot * sizeof(*cfg);
+	int err = 0;
 
 	ufshcd_hold(hba, false);
+
+	if (hba->vops && hba->vops->program_key) {
+		err = hba->vops->program_key(hba, cfg, slot);
+		goto out;
+	}
+
 	/* Ensure that CFGE is cleared before programming the key */
 	ufshcd_writel(hba, 0, slot_offset + 16 * sizeof(cfg->reg_val[0]));
 	for (i = 0; i < 16; i++) {
@@ -151,23 +157,28 @@ static void ufshcd_program_key(struct ufs_hba *hba,
 	/* Dword 16 must be written last */
 	ufshcd_writel(hba, le32_to_cpu(cfg->reg_val[16]),
 		      slot_offset + 16 * sizeof(cfg->reg_val[0]));
+out:
 	ufshcd_release(hba);
+	return err;
 }
 
-static void ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
+static int ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
 {
 	union ufs_crypto_cfg_entry cfg = { 0 };
 
-	ufshcd_program_key(hba, &cfg, slot);
+	return ufshcd_program_key(hba, &cfg, slot);
 }
 
 /* Clear all keyslots at driver init time */  static void
ufshcd_clear_all_keyslots(struct ufs_hba *hba)  {
 	int slot;
+	int err;
 
-	for (slot = 0; slot < ufshcd_num_keyslots(hba); slot++)
-		ufshcd_clear_keyslot(hba, slot);
+	for (slot = 0; slot < ufshcd_num_keyslots(hba); slot++) {
+		err = ufshcd_clear_keyslot(hba, slot);
+		WARN_ON_ONCE(err);
+	}
 }
 
 static int ufshcd_crypto_keyslot_program(struct keyslot_manager *ksm, @@
-203,10 +214,11 @@ static int ufshcd_crypto_keyslot_program(struct
keyslot_manager *ksm,
 	if (err)
 		return err;
 
-	ufshcd_program_key(hba, &cfg, slot);
+	err = ufshcd_program_key(hba, &cfg, slot);
 
 	memzero_explicit(&cfg, sizeof(cfg));
-	return 0;
+
+	return err;
 }
 
 static int ufshcd_crypto_keyslot_evict(struct keyslot_manager *ksm, @@
-223,9 +235,7 @@ static int ufshcd_crypto_keyslot_evict(struct
keyslot_manager *ksm,
 	 * Clear the crypto cfg on the device. Clearing CFGE
 	 * might not be sufficient, so just clear the entire cfg.
 	 */
-	ufshcd_clear_keyslot(hba, slot);
-
-	return 0;
+	return ufshcd_clear_keyslot(hba, slot);
 }
 
 void ufshcd_crypto_enable(struct ufs_hba *hba) diff --git
a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index
c8f948aa5e3d..c2656575e24b 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -306,6 +306,7 @@ struct ufs_pwr_mode_info {
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
  * @device_reset: called to issue a reset pulse on the UFS device
+ * @program_key: program or evict an inline encryption key
  */
 struct ufs_hba_variant_ops {
 	const char *name;
@@ -335,6 +336,8 @@ struct ufs_hba_variant_ops {
 	void	(*dbg_register_dump)(struct ufs_hba *hba);
 	int	(*phy_initialization)(struct ufs_hba *);
 	void	(*device_reset)(struct ufs_hba *hba);
+	int	(*program_key)(struct ufs_hba *hba,
+			       const union ufs_crypto_cfg_entry *cfg, int
slot);
 };
 
 /* clock gating state  */
--
2.25.1

Re: [RFC PATCH v2 3/4] scsi: ufs: add program_key() variant op

[Eric Biggers]

Hi Barani,

On Wed, Mar 04, 2020 at 12:18:20PM -0800, bmuthuku@codeaurora.org wrote:
> Eric, I strongly recommend not to support the old mechanism of calling into
> TEE to set keys as this has been deprecated and will not work with newer
> hardware. 

Actually, I've also verified that this driver works nearly as-is on Snapdragon
865 and Snapdragon 765.  (Those SoCs currently lack upstream support, but I
tested with downstream kernels.)  IIUC, this is the latest Qualcomm hardware in
the real world.  Lots of phones will be shipping with those SoCS this year.

So your position is that crypto support for current Qualcomm hardware shouldn't
be added, and instead we should wait years for new hardware that hasn't even
been announced/released yet and has no upstream kernel support at all yet?
Snapdragon 845 (via DragonBoard 845c) already has upstream support.

We can easily support multiple hardware versions in the driver, so I don't see
why this is an issue.

In particular, if Qualcomm releases new hardware that just complies with the UFS
standard and doesn't require these weird vendor-specific SCM calls, we can just
conditionally skip the quirks when standard hardware is detected.

> There are few issues with this patch, it adds all the code within
> UFS and we would have to reimplement all the common ICE code for eMMC as
> well.

The downstream solution of having a separate ICE "device" and "driver" is really
horrendous and results in lots of layering violations and unnecessary code,
since as far as I can tell ICE is actually part of the UFS and eMMC controllers
and not a separate device.

So I think starting with the ICE logic in ufs-qcom is the right approach.

If it turns out that sdhci-msm needs similar ICE management code, we can put it
in a library.  Though, note that after I removed all the unneeded stuff, we're
only talking about ~200 lines of code, so it may not even be worthwhile.

However, an issue with eMMC is that the eMMC crypto standard hasn't actually
been published yet.  And I haven't heard of any vendors implementing it besides
Qualcomm, nor do I know of any upstream SoC we can use to develop it.

So if you want eMMC crypto support, you're going to have to help with it.

> For clearing a key, the patch uses program_key to set zeroes to the
> keyslot, without going into details (since newer hardware is not yet public)
> this will not work.

That's incorrect; this patch uses the SCM call QCOM_SCM_ES_INVALIDATE_ICE_KEY to
evict keys.  That's exactly what the downstream driver does.

Of course, when we add support for newer hardware we can use whatever keyslot
management method works on that hardware.  Hopefully, it's the standard UFS
method and not another weird vendor-specific method.

> We have a plan to upstream ICE support with the new hardware along with the
> framework to support wrapped keys and add sdhci/cqhci-crypto support.

Great, what's the timeline on this?  Are there patches you can point to
anywhere?  How would one get ahold of this hardware, and does it / will it have
upstream kernel support like sda845 does?

- Eric

Re: [RFC PATCH v2 1/4] firmware: qcom_scm: Add support for programming inline crypto keys

[Eric Biggers]

On Wed, Mar 04, 2020 at 09:04:49AM -0800, Stephen Boyd wrote:
> Quoting Eric Biggers (2020-03-03 22:49:39)
> > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> > index 059bb0fbae9e..7fb9f606250f 100644
> > --- a/drivers/firmware/qcom_scm.c
> > +++ b/drivers/firmware/qcom_scm.c
> > @@ -926,6 +927,101 @@ int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
> [...]
> > +
> > +/**
> > + * qcom_scm_ice_set_key() - Set an inline encryption key
> > + * @index: the keyslot into which to set the key
> > + * @key: the key to program
> > + * @key_size: the size of the key in bytes
> > + * @cipher: the encryption algorithm the key is for
> > + * @data_unit_size: the encryption data unit size, i.e. the size of each
> > + *                 individual plaintext and ciphertext.  Given in 512-byte
> > + *                 units, e.g. 1 = 512 bytes, 8 = 4096 bytes, etc.
> > + *
> > + * Program a key into a keyslot of Qualcomm ICE (Inline Crypto Engine), where it
> > + * can then be used to encrypt/decrypt UFS I/O requests inline.
> > + *
> > + * The UFSHCI standard defines a standard way to do this, but it doesn't work on
> > + * these SoCs; only this SCM call does.
> > + *
> > + * Return: 0 on success; -errno on failure.
> > + */
> > +int qcom_scm_ice_set_key(u32 index, const u8 *key, int key_size,
> > +                        enum qcom_scm_ice_cipher cipher, int data_unit_size)
> 
> Why not make key_size and data_unit_size unsigned?

No reason other than that 'int' is fewer characters and is a good default when
no other particular type is warranted.  But I can change them to 'unsigned int'
if people prefer to make it clearer that they can't be negative.

> 
> > +{
> > +       struct qcom_scm_desc desc = {
> > +               .svc = QCOM_SCM_SVC_ES,
> > +               .cmd = QCOM_SCM_ES_CONFIG_SET_ICE_KEY,
> > +               .arginfo = QCOM_SCM_ARGS(5, QCOM_SCM_VAL, QCOM_SCM_RW,
> > +                                        QCOM_SCM_VAL, QCOM_SCM_VAL,
> > +                                        QCOM_SCM_VAL),
> > +               .args[0] = index,
> > +               .args[2] = key_size,
> > +               .args[3] = cipher,
> > +               .args[4] = data_unit_size,
> > +               .owner = ARM_SMCCC_OWNER_SIP,
> > +       };
> > +       u8 *keybuf;
> > +       dma_addr_t key_phys;
> > +       int ret;
> > +
> > +       keybuf = kmemdup(key, key_size, GFP_KERNEL);
> 
> Is this to make the key physically contiguous? Probably worth a comment
> to help others understand why this is here.

Yes, dma_map_single() requires physically contiguous memory.  I'll add a
comment.

> 
> > +       if (!keybuf)
> > +               return -ENOMEM;
> > +
> > +       key_phys = dma_map_single(__scm->dev, keybuf, key_size, DMA_TO_DEVICE);
> > +       if (dma_mapping_error(__scm->dev, key_phys)) {
> > +               ret = -ENOMEM;
> > +               goto out;
> > +       }
> > +       desc.args[1] = key_phys;
> > +
> > +       ret = qcom_scm_call(__scm->dev, &desc, NULL);
> > +
> > +       dma_unmap_single(__scm->dev, key_phys, key_size, DMA_TO_DEVICE);
> > +out:
> > +       kzfree(keybuf);
> 
> And this is because we want to clear key contents out of the slab? What
> about if the dma_map_single() bounces to a bounce buffer? I think that
> isn't going to happen because __scm->dev is just some firmware device
> that doesn't require bounce buffers but it's worth another comment to
> clarify this.

Yes, in crypto-related code we always try to wipe keys after use.  I don't think
a bounce buffer would actually be used here, though it would be preferable to
wipe the DMA memory too so that we don't rely on that.  But I didn't see how to
do that; I'm not a DMA API expert.  Maybe dma_alloc_coherent()?  This isn't
really performance-critical.

- Eric