* [RFC PATCH v4 1/4] firmware: qcom_scm: Add support for programming inline crypto keys
2020-05-01 4:51 [RFC PATCH v4 0/4] Inline crypto support on DragonBoard 845c Eric Biggers
@ 2020-05-01 4:51 ` Eric Biggers
2020-05-07 12:39 ` Thara Gopinath
2020-06-17 6:48 ` Bjorn Andersson
2020-05-01 4:51 ` [RFC PATCH v4 2/4] arm64: dts: sdm845: add Inline Crypto Engine registers and clock Eric Biggers
` (2 subsequent siblings)
3 siblings, 2 replies; 20+ messages in thread
From: Eric Biggers @ 2020-05-01 4:51 UTC (permalink / raw)
To: linux-scsi, linux-arm-msm
Cc: linux-block, linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
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 | 101 ++++++++++++++++++++++++++++++++++++
drivers/firmware/qcom_scm.h | 4 ++
include/linux/qcom_scm.h | 19 +++++++
3 files changed, 124 insertions(+)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 059bb0fbae9e5b..646f9613393612 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -926,6 +926,107 @@ 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, u32 key_size,
+ enum qcom_scm_ice_cipher cipher, u32 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,
+ };
+ void *keybuf;
+ dma_addr_t key_phys;
+ int ret;
+
+ /*
+ * 'key' may point to vmalloc()'ed memory, but we need to pass a
+ * physical address that's been properly flushed. The sanctioned way to
+ * do this is by using the DMA API. But as is best practice for crypto
+ * keys, we also must wipe the key after use. This makes kmemdup() +
+ * dma_map_single() not clearly correct, since the DMA API can use
+ * bounce buffers. Instead, just use dma_alloc_coherent(). Programming
+ * keys is normally rare and thus not performance-critical.
+ */
+
+ keybuf = dma_alloc_coherent(__scm->dev, key_size, &key_phys,
+ GFP_KERNEL);
+ if (!keybuf)
+ return -ENOMEM;
+ memcpy(keybuf, key, key_size);
+ desc.args[1] = key_phys;
+
+ ret = qcom_scm_call(__scm->dev, &desc, NULL);
+
+ memzero_explicit(keybuf, key_size);
+
+ dma_free_coherent(__scm->dev, key_size, keybuf, key_phys);
+ 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 d9ed670da222c8..38ea614d29fea2 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 3d6a2469776153..2e1193a3fb5f06 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, u32 key_size,
+ enum qcom_scm_ice_cipher cipher,
+ u32 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, u32 key_size,
+ enum qcom_scm_ice_cipher cipher,
+ u32 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.26.2
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 1/4] firmware: qcom_scm: Add support for programming inline crypto keys
2020-05-01 4:51 ` [RFC PATCH v4 1/4] firmware: qcom_scm: Add support for programming inline crypto keys Eric Biggers
@ 2020-05-07 12:39 ` Thara Gopinath
2020-06-17 6:48 ` Bjorn Andersson
1 sibling, 0 replies; 20+ messages in thread
From: Thara Gopinath @ 2020-05-07 12:39 UTC (permalink / raw)
To: Eric Biggers, linux-scsi, linux-arm-msm
Cc: linux-block, linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
On 5/1/20 12:51 AM, Eric Biggers wrote:
> 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 | 101 ++++++++++++++++++++++++++++++++++++
> drivers/firmware/qcom_scm.h | 4 ++
> include/linux/qcom_scm.h | 19 +++++++
> 3 files changed, 124 insertions(+)
>
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 059bb0fbae9e5b..646f9613393612 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -926,6 +926,107 @@ 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/s/iff/if
--
Warm Regards
Thara
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 1/4] firmware: qcom_scm: Add support for programming inline crypto keys
2020-05-01 4:51 ` [RFC PATCH v4 1/4] firmware: qcom_scm: Add support for programming inline crypto keys Eric Biggers
2020-05-07 12:39 ` Thara Gopinath
@ 2020-06-17 6:48 ` Bjorn Andersson
1 sibling, 0 replies; 20+ messages in thread
From: Bjorn Andersson @ 2020-06-17 6:48 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Can Guo, Elliot Berman, John Stultz, Satya Tangirala
On Thu 30 Apr 21:51 PDT 2020, Eric Biggers wrote:
> 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>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> drivers/firmware/qcom_scm.c | 101 ++++++++++++++++++++++++++++++++++++
> drivers/firmware/qcom_scm.h | 4 ++
> include/linux/qcom_scm.h | 19 +++++++
> 3 files changed, 124 insertions(+)
>
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 059bb0fbae9e5b..646f9613393612 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -926,6 +926,107 @@ 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, u32 key_size,
> + enum qcom_scm_ice_cipher cipher, u32 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,
> + };
> + void *keybuf;
> + dma_addr_t key_phys;
> + int ret;
> +
> + /*
> + * 'key' may point to vmalloc()'ed memory, but we need to pass a
> + * physical address that's been properly flushed. The sanctioned way to
> + * do this is by using the DMA API. But as is best practice for crypto
> + * keys, we also must wipe the key after use. This makes kmemdup() +
> + * dma_map_single() not clearly correct, since the DMA API can use
> + * bounce buffers. Instead, just use dma_alloc_coherent(). Programming
> + * keys is normally rare and thus not performance-critical.
> + */
> +
> + keybuf = dma_alloc_coherent(__scm->dev, key_size, &key_phys,
> + GFP_KERNEL);
> + if (!keybuf)
> + return -ENOMEM;
> + memcpy(keybuf, key, key_size);
> + desc.args[1] = key_phys;
> +
> + ret = qcom_scm_call(__scm->dev, &desc, NULL);
> +
> + memzero_explicit(keybuf, key_size);
> +
> + dma_free_coherent(__scm->dev, key_size, keybuf, key_phys);
> + 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 d9ed670da222c8..38ea614d29fea2 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 3d6a2469776153..2e1193a3fb5f06 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, u32 key_size,
> + enum qcom_scm_ice_cipher cipher,
> + u32 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, u32 key_size,
> + enum qcom_scm_ice_cipher cipher,
> + u32 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.26.2
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* [RFC PATCH v4 2/4] arm64: dts: sdm845: add Inline Crypto Engine registers and clock
2020-05-01 4:51 [RFC PATCH v4 0/4] Inline crypto support on DragonBoard 845c Eric Biggers
2020-05-01 4:51 ` [RFC PATCH v4 1/4] firmware: qcom_scm: Add support for programming inline crypto keys Eric Biggers
@ 2020-05-01 4:51 ` Eric Biggers
2020-05-01 4:51 ` [RFC PATCH v4 3/4] scsi: ufs: add program_key() variant op Eric Biggers
2020-05-01 4:51 ` [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support Eric Biggers
3 siblings, 0 replies; 20+ messages in thread
From: Eric Biggers @ 2020-05-01 4:51 UTC (permalink / raw)
To: linux-scsi, linux-arm-msm
Cc: linux-block, linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
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 8f926b5234d40c..dfb0454049b949 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1691,7 +1691,9 @@ mmss_noc: interconnect@1740000 {
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";
@@ -1711,7 +1713,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>,
@@ -1720,7 +1723,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>,
@@ -1729,7 +1733,8 @@ ufs_mem_hc: ufshc@1d84000 {
<0 0>,
<0 0>,
<0 0>,
- <0 0>;
+ <0 0>,
+ <0 300000000>;
status = "disabled";
};
--
2.26.2
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [RFC PATCH v4 3/4] scsi: ufs: add program_key() variant op
2020-05-01 4:51 [RFC PATCH v4 0/4] Inline crypto support on DragonBoard 845c Eric Biggers
2020-05-01 4:51 ` [RFC PATCH v4 1/4] firmware: qcom_scm: Add support for programming inline crypto keys Eric Biggers
2020-05-01 4:51 ` [RFC PATCH v4 2/4] arm64: dts: sdm845: add Inline Crypto Engine registers and clock Eric Biggers
@ 2020-05-01 4:51 ` Eric Biggers
2020-05-01 4:51 ` [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support Eric Biggers
3 siblings, 0 replies; 20+ messages in thread
From: Eric Biggers @ 2020-05-01 4:51 UTC (permalink / raw)
To: linux-scsi, linux-arm-msm
Cc: linux-block, linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
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 | 27 +++++++++++++++++----------
drivers/scsi/ufs/ufshcd.h | 3 +++
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd-crypto.c b/drivers/scsi/ufs/ufshcd-crypto.c
index 65a3115d2a2d47..717a7eb6298839 100644
--- a/drivers/scsi/ufs/ufshcd-crypto.c
+++ b/drivers/scsi/ufs/ufshcd-crypto.c
@@ -17,14 +17,20 @@ static const struct ufs_crypto_alg_entry {
},
};
-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++) {
@@ -37,7 +43,9 @@ 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 int ufshcd_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
@@ -52,6 +60,7 @@ static int ufshcd_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
int i;
int cap_idx = -1;
union ufs_crypto_cfg_entry cfg = { 0 };
+ int err;
BUILD_BUG_ON(UFS_CRYPTO_KEY_SIZE_INVALID != 0);
for (i = 0; i < hba->crypto_capabilities.num_crypto_cap; i++) {
@@ -79,13 +88,13 @@ static int ufshcd_crypto_keyslot_program(struct blk_keyslot_manager *ksm,
memcpy(cfg.crypto_key, key->raw, key->size);
}
- ufshcd_program_key(hba, &cfg, slot);
+ err = ufshcd_program_key(hba, &cfg, slot);
memzero_explicit(&cfg, sizeof(cfg));
- return 0;
+ return err;
}
-static void ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
+static int ufshcd_clear_keyslot(struct ufs_hba *hba, int slot)
{
/*
* Clear the crypto cfg on the device. Clearing CFGE
@@ -93,7 +102,7 @@ static void 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);
}
static int ufshcd_crypto_keyslot_evict(struct blk_keyslot_manager *ksm,
@@ -102,9 +111,7 @@ static int ufshcd_crypto_keyslot_evict(struct blk_keyslot_manager *ksm,
{
struct ufs_hba *hba = container_of(ksm, struct ufs_hba, ksm);
- ufshcd_clear_keyslot(hba, slot);
-
- return 0;
+ return ufshcd_clear_keyslot(hba, slot);
}
bool ufshcd_crypto_enable(struct ufs_hba *hba)
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 8de208b74f95fc..0d424f59952169 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -319,6 +319,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;
@@ -351,6 +352,8 @@ struct ufs_hba_variant_ops {
void (*config_scaling_param)(struct ufs_hba *hba,
struct devfreq_dev_profile *profile,
void *data);
+ int (*program_key)(struct ufs_hba *hba,
+ const union ufs_crypto_cfg_entry *cfg, int slot);
};
/* clock gating state */
--
2.26.2
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-01 4:51 [RFC PATCH v4 0/4] Inline crypto support on DragonBoard 845c Eric Biggers
` (2 preceding siblings ...)
2020-05-01 4:51 ` [RFC PATCH v4 3/4] scsi: ufs: add program_key() variant op Eric Biggers
@ 2020-05-01 4:51 ` Eric Biggers
2020-05-07 12:36 ` Thara Gopinath
3 siblings, 1 reply; 20+ messages in thread
From: Eric Biggers @ 2020-05-01 4:51 UTC (permalink / raw)
To: linux-scsi, linux-arm-msm
Cc: linux-block, linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
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 and runs the upstream
Linux kernel. 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, both manually using ext4 encryption
and automatically using a block layer self-test I've written.
This driver also works nearly as-is on Snapdragon 765 and Snapdragon
865, which are very recent SoCs, having just been announced in Dec 2019
(though these newer SoCs currently lack upstream kernel support).
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 | 245 ++++++++++++++++++++++++++++++++
drivers/scsi/ufs/ufs-qcom.c | 12 +-
drivers/scsi/ufs/ufs-qcom.h | 27 ++++
6 files changed, 288 insertions(+), 3 deletions(-)
create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 26f281d9f32a4a..cab5fe76784592 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2236,7 +2236,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-geni-qcom.c
F: drivers/spi/spi-qcom-qspi.c
F: drivers/spi/spi-qup.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 5ed3f209f88100..c1a94d99e161ee 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 197e178f44bce3..13fda1b697b2a2 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 00000000000000..9e837fdcb0ac2b
--- /dev/null
+++ b/drivers/scsi/ufs/ufs-qcom-ice.c
@@ -0,0 +1,245 @@
+// 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)) {
+ err = PTR_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->caps &= ~UFSHCD_CAP_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);
+
+ /*
+ * 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 19aa5c44e0da6f..37c4070c9007ef 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);
@@ -614,6 +614,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;
}
@@ -1071,6 +1075,7 @@ static void ufs_qcom_set_caps(struct ufs_hba *hba)
hba->caps |= UFSHCD_CAP_CLK_GATING | UFSHCD_CAP_HIBERN8_WITH_CLK_GATING;
hba->caps |= UFSHCD_CAP_CLK_SCALING;
hba->caps |= UFSHCD_CAP_AUTO_BKOPS_SUSPEND;
+ hba->caps |= UFSHCD_CAP_CRYPTO;
if (host->hw_ver.major >= 0x2) {
host->caps = UFS_QCOM_CAP_QUNIPRO |
@@ -1297,6 +1302,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_set_bus_vote(hba, true);
ufs_qcom_setup_clocks(hba, true, POST_CHANGE);
@@ -1735,6 +1744,7 @@ static const struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
.dbg_register_dump = ufs_qcom_dump_dbg_regs,
.device_reset = ufs_qcom_device_reset,
.config_scaling_param = ufs_qcom_config_scaling_param,
+ .program_key = ufs_qcom_ice_program_key,
};
/**
diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
index 2d95e7cc71874e..97247d17e258ad 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.26.2
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-01 4:51 ` [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support Eric Biggers
@ 2020-05-07 12:36 ` Thara Gopinath
2020-05-07 18:04 ` Eric Biggers
0 siblings, 1 reply; 20+ messages in thread
From: Thara Gopinath @ 2020-05-07 12:36 UTC (permalink / raw)
To: Eric Biggers, linux-scsi, linux-arm-msm
Cc: linux-block, linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
On 5/1/20 12:51 AM, Eric Biggers wrote:
> 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 and runs the upstream
> Linux kernel. 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, both manually using ext4 encryption
> and automatically using a block layer self-test I've written.
Hello Eric,
I am interested in testing out this series on 845, 855 and if possile on
865 platforms. Can you give me some more details about your testing please.
>
> This driver also works nearly as-is on Snapdragon 765 and Snapdragon
> 865, which are very recent SoCs, having just been announced in Dec 2019
> (though these newer SoCs currently lack upstream kernel support).
>
> 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 | 245 ++++++++++++++++++++++++++++++++
> drivers/scsi/ufs/ufs-qcom.c | 12 +-
> drivers/scsi/ufs/ufs-qcom.h | 27 ++++
> 6 files changed, 288 insertions(+), 3 deletions(-)
> create mode 100644 drivers/scsi/ufs/ufs-qcom-ice.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 26f281d9f32a4a..cab5fe76784592 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2236,7 +2236,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-geni-qcom.c
> F: drivers/spi/spi-qcom-qspi.c
> F: drivers/spi/spi-qup.c
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 5ed3f209f88100..c1a94d99e161ee 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 197e178f44bce3..13fda1b697b2a2 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 00000000000000..9e837fdcb0ac2b
> --- /dev/null
> +++ b/drivers/scsi/ufs/ufs-qcom-ice.c
> @@ -0,0 +1,245 @@
> +// 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)) {
> + err = PTR_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->caps &= ~UFSHCD_CAP_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;
Should there not be a check for here ?
if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
return 0;
--
Warm Regards
Thara
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-07 12:36 ` Thara Gopinath
@ 2020-05-07 18:04 ` Eric Biggers
2020-05-07 18:08 ` Eric Biggers
0 siblings, 1 reply; 20+ messages in thread
From: Eric Biggers @ 2020-05-07 18:04 UTC (permalink / raw)
To: Thara Gopinath
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
Hi Thara,
On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
>
>
> On 5/1/20 12:51 AM, Eric Biggers wrote:
> > 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 and runs the upstream
> > Linux kernel. 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, both manually using ext4 encryption
> > and automatically using a block layer self-test I've written.
> Hello Eric,
>
> I am interested in testing out this series on 845, 855 and if possile on 865
> platforms. Can you give me some more details about your testing please.
>
Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
A basic manual test would be:
1. Build a kernel with:
CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
2. Create a filesystem with 'mkfs.ext4 -O encrypt' or 'mkfs.f2fs -O encrypt'
3. Mount the filesystem with '-o inlinecrypt'
4. Create an encrypted directory and copy some files into it.
5. Unmount the filesystem, and mount it *without* '-o inlinecrypt'.
6. Verify that the files match the originals.
If you're using a Linux distro like Debian, then creating an encrypted directory
is most easily done using the userspace tool https://github.com/google/fscrypt.
If instead your testing platform is Android, then instead of the above manual
test you can configure Android's encryption use the hardware and then run
VtsKernelEncryptionTest. See the directions at
https://source.android.com/security/encryption/file-based.
Note that this patchset only includes the device tree support for Snapdragon
845. For 855 and 865 you'd need to add the device tree support.
There are other ways this can be tested too, like xfstests, or my experimental
blk-crypto-selftest. Let me know if you want any other suggestions.
> > +/*
> > + * 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;
> Should there not be a check for here ?
> if (!(host->hba->caps & UFSHCD_CAP_CRYPTO))
> return 0;
>
(Please trim your replies appropriately; I almost missed this part!)
No, that's not necessary because this function is only called if we installed a
blk_keyslot_manager to the UFS host (thus exposing its crypto support to the
rest of the kernel). We only do that if the driver sets UFSHCD_CAP_CRYPTO.
Likewise, we don't need to check for UFSHCD_CAP_CRYPTO in
ufshcd_crypto_keyslot_program(), ufshcd_crypto_keyslot_evict(), etc.
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-07 18:04 ` Eric Biggers
@ 2020-05-07 18:08 ` Eric Biggers
2020-05-08 20:18 ` Steev Klimaszewski
2020-05-29 15:54 ` Thara Gopinath
0 siblings, 2 replies; 20+ messages in thread
From: Eric Biggers @ 2020-05-07 18:08 UTC (permalink / raw)
To: Thara Gopinath
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
> Hi Thara,
>
> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
> >
> >
> > On 5/1/20 12:51 AM, Eric Biggers wrote:
> > > 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 and runs the upstream
> > > Linux kernel. 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, both manually using ext4 encryption
> > > and automatically using a block layer self-test I've written.
> > Hello Eric,
> >
> > I am interested in testing out this series on 845, 855 and if possile on 865
> > platforms. Can you give me some more details about your testing please.
> >
>
> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
>
> A basic manual test would be:
>
> 1. Build a kernel with:
>
> CONFIG_BLK_INLINE_ENCRYPTION=y
> CONFIG_FS_ENCRYPTION=y
> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-07 18:08 ` Eric Biggers
@ 2020-05-08 20:18 ` Steev Klimaszewski
2020-05-08 20:25 ` Eric Biggers
2020-05-29 15:54 ` Thara Gopinath
1 sibling, 1 reply; 20+ messages in thread
From: Steev Klimaszewski @ 2020-05-08 20:18 UTC (permalink / raw)
To: Eric Biggers, Thara Gopinath
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
On 5/7/20 1:08 PM, Eric Biggers wrote:
> On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
>> Hi Thara,
>>
>> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
>>>
>>> On 5/1/20 12:51 AM, Eric Biggers wrote:
>>>> 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 and runs the upstream
>>>> Linux kernel. 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, both manually using ext4 encryption
>>>> and automatically using a block layer self-test I've written.
>>> Hello Eric,
>>>
>>> I am interested in testing out this series on 845, 855 and if possile on 865
>>> platforms. Can you give me some more details about your testing please.
>>>
>> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
>>
>> A basic manual test would be:
>>
>> 1. Build a kernel with:
>>
>> CONFIG_BLK_INLINE_ENCRYPTION=y
>> CONFIG_FS_ENCRYPTION=y
>> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
>
> - Eric
I took a look into this as well - is v12 the latest of the fscrypt
inline crypto patches?
I see a EXPORT_SYMBOL_GPL(fscrypt_inode_uses_inline_crypto) but it seems
like it should be EXPORT_SYMBOL_GPL(__fscrypt_inode_uses_inline_crypto)
otherwise you end up with
WARNING: modpost: "fscrypt_inode_uses_inline_crypto" [vmlinux] is a
static EXPORT_SYMBOL_GPL
when you have something like CONFIG_F2FS_FS=m
Apologies but I'm not sure where the original patchset is to send as a
reply to them.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-08 20:18 ` Steev Klimaszewski
@ 2020-05-08 20:25 ` Eric Biggers
2020-05-08 20:29 ` Satya Tangirala
2020-06-12 18:04 ` Steev Klimaszewski
0 siblings, 2 replies; 20+ messages in thread
From: Eric Biggers @ 2020-05-08 20:25 UTC (permalink / raw)
To: Steev Klimaszewski
Cc: Thara Gopinath, linux-scsi, linux-arm-msm, linux-block,
linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
On Fri, May 08, 2020 at 03:18:23PM -0500, Steev Klimaszewski wrote:
>
> On 5/7/20 1:08 PM, Eric Biggers wrote:
> > On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
> >> Hi Thara,
> >>
> >> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
> >>>
> >>> On 5/1/20 12:51 AM, Eric Biggers wrote:
> >>>> 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 and runs the upstream
> >>>> Linux kernel. 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, both manually using ext4 encryption
> >>>> and automatically using a block layer self-test I've written.
> >>> Hello Eric,
> >>>
> >>> I am interested in testing out this series on 845, 855 and if possile on 865
> >>> platforms. Can you give me some more details about your testing please.
> >>>
> >> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
> >>
> >> A basic manual test would be:
> >>
> >> 1. Build a kernel with:
> >>
> >> CONFIG_BLK_INLINE_ENCRYPTION=y
> >> CONFIG_FS_ENCRYPTION=y
> >> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> > Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
> >
> > - Eric
>
> I took a look into this as well - is v12 the latest of the fscrypt
> inline crypto patches?
>
> I see a EXPORT_SYMBOL_GPL(fscrypt_inode_uses_inline_crypto) but it seems
> like it should be EXPORT_SYMBOL_GPL(__fscrypt_inode_uses_inline_crypto)
> otherwise you end up with
>
>
> WARNING: modpost: "fscrypt_inode_uses_inline_crypto" [vmlinux] is a
> static EXPORT_SYMBOL_GPL
>
>
> when you have something like CONFIG_F2FS_FS=m
>
>
> Apologies but I'm not sure where the original patchset is to send as a
> reply to them.
The original patchset is at
https://lkml.kernel.org/r/20200430115959.238073-1-satyat@google.com/
Yes, v12 is the latest version, and yes that's a bug. The export needs double
underscores. Satya will fix it when he sends out v13.
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-08 20:25 ` Eric Biggers
@ 2020-05-08 20:29 ` Satya Tangirala
2020-06-12 18:04 ` Steev Klimaszewski
1 sibling, 0 replies; 20+ messages in thread
From: Satya Tangirala @ 2020-05-08 20:29 UTC (permalink / raw)
To: Eric Biggers
Cc: Steev Klimaszewski, Thara Gopinath, linux-scsi, linux-arm-msm,
linux-block, linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz
On Fri, May 08, 2020 at 01:25:13PM -0700, Eric Biggers wrote:
> On Fri, May 08, 2020 at 03:18:23PM -0500, Steev Klimaszewski wrote:
> >
> > On 5/7/20 1:08 PM, Eric Biggers wrote:
> > > On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
> > >> Hi Thara,
> > >>
> > >> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
> > >>>
> > >>> On 5/1/20 12:51 AM, Eric Biggers wrote:
> > >>>> 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 and runs the upstream
> > >>>> Linux kernel. 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, both manually using ext4 encryption
> > >>>> and automatically using a block layer self-test I've written.
> > >>> Hello Eric,
> > >>>
> > >>> I am interested in testing out this series on 845, 855 and if possile on 865
> > >>> platforms. Can you give me some more details about your testing please.
> > >>>
> > >> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
> > >>
> > >> A basic manual test would be:
> > >>
> > >> 1. Build a kernel with:
> > >>
> > >> CONFIG_BLK_INLINE_ENCRYPTION=y
> > >> CONFIG_FS_ENCRYPTION=y
> > >> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> > > Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
> > >
> > > - Eric
> >
> > I took a look into this as well - is v12 the latest of the fscrypt
> > inline crypto patches?
> >
> > I see a EXPORT_SYMBOL_GPL(fscrypt_inode_uses_inline_crypto) but it seems
> > like it should be EXPORT_SYMBOL_GPL(__fscrypt_inode_uses_inline_crypto)
> > otherwise you end up with
> >
> >
> > WARNING: modpost: "fscrypt_inode_uses_inline_crypto" [vmlinux] is a
> > static EXPORT_SYMBOL_GPL
> >
> >
> > when you have something like CONFIG_F2FS_FS=m
> >
> >
> > Apologies but I'm not sure where the original patchset is to send as a
> > reply to them.
>
> The original patchset is at
> https://lkml.kernel.org/r/20200430115959.238073-1-satyat@google.com/
>
> Yes, v12 is the latest version, and yes that's a bug. The export needs double
> underscores. Satya will fix it when he sends out v13.
>
> - Eric
Yup, that's the plan. Thanks!
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-08 20:25 ` Eric Biggers
2020-05-08 20:29 ` Satya Tangirala
@ 2020-06-12 18:04 ` Steev Klimaszewski
2020-06-15 18:58 ` Eric Biggers
1 sibling, 1 reply; 20+ messages in thread
From: Steev Klimaszewski @ 2020-06-12 18:04 UTC (permalink / raw)
To: Eric Biggers
Cc: Thara Gopinath, linux-scsi, linux-arm-msm, linux-block,
linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
On 5/8/20 3:25 PM, Eric Biggers wrote:
> On Fri, May 08, 2020 at 03:18:23PM -0500, Steev Klimaszewski wrote:
>> On 5/7/20 1:08 PM, Eric Biggers wrote:
>>> On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
>>>> Hi Thara,
>>>>
>>>> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
>>>>> On 5/1/20 12:51 AM, Eric Biggers wrote:
>>>>>> 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 and runs the upstream
>>>>>> Linux kernel. 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, both manually using ext4 encryption
>>>>>> and automatically using a block layer self-test I've written.
>>>>> Hello Eric,
>>>>>
>>>>> I am interested in testing out this series on 845, 855 and if possile on 865
>>>>> platforms. Can you give me some more details about your testing please.
>>>>>
>>>> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
>>>>
>>>> A basic manual test would be:
>>>>
>>>> 1. Build a kernel with:
>>>>
>>>> CONFIG_BLK_INLINE_ENCRYPTION=y
>>>> CONFIG_FS_ENCRYPTION=y
>>>> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
>>> Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
>>>
>>> - Eric
>>
> The original patchset is at
> https://lkml.kernel.org/r/20200430115959.238073-1-satyat@google.com/
>
> Yes, v12 is the latest version, and yes that's a bug. The export needs double
> underscores. Satya will fix it when he sends out v13.
>
> - Eric
Hi Eric,
I've been testing this on a Lenovo Yoga C630 installed to a partition on
the UFS drive, using a 5.7(ish) kernel with fscrypt/inline-encryption
and a few patches on top that are still in flux for c630 support. The
sources I use can be found at
https://github.com/steev/linux/tree/linux-5.7.y-c630-fscrypt and the
config I'm using can be found at
https://dev.gentoo.org/~steev/files/lenovo-yoga-c630-5.7.0-rc7-fs-inline-encryption.config.
Everything seems to be working here. I've run the tests you've
mentioned and haven't seen any issues.
-- Steev
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-06-12 18:04 ` Steev Klimaszewski
@ 2020-06-15 18:58 ` Eric Biggers
2020-06-15 19:07 ` Steev Klimaszewski
0 siblings, 1 reply; 20+ messages in thread
From: Eric Biggers @ 2020-06-15 18:58 UTC (permalink / raw)
To: Steev Klimaszewski
Cc: Thara Gopinath, linux-scsi, linux-arm-msm, linux-block,
linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
On Fri, Jun 12, 2020 at 01:04:33PM -0500, Steev Klimaszewski wrote:
>
> On 5/8/20 3:25 PM, Eric Biggers wrote:
> > On Fri, May 08, 2020 at 03:18:23PM -0500, Steev Klimaszewski wrote:
> >> On 5/7/20 1:08 PM, Eric Biggers wrote:
> >>> On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
> >>>> Hi Thara,
> >>>>
> >>>> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
> >>>>> On 5/1/20 12:51 AM, Eric Biggers wrote:
> >>>>>> 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 and runs the upstream
> >>>>>> Linux kernel. 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, both manually using ext4 encryption
> >>>>>> and automatically using a block layer self-test I've written.
> >>>>> Hello Eric,
> >>>>>
> >>>>> I am interested in testing out this series on 845, 855 and if possile on 865
> >>>>> platforms. Can you give me some more details about your testing please.
> >>>>>
> >>>> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
> >>>>
> >>>> A basic manual test would be:
> >>>>
> >>>> 1. Build a kernel with:
> >>>>
> >>>> CONFIG_BLK_INLINE_ENCRYPTION=y
> >>>> CONFIG_FS_ENCRYPTION=y
> >>>> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> >>> Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
> >>>
> >>> - Eric
> >>
> > The original patchset is at
> > https://lkml.kernel.org/r/20200430115959.238073-1-satyat@google.com/
> >
> > Yes, v12 is the latest version, and yes that's a bug. The export needs double
> > underscores. Satya will fix it when he sends out v13.
> >
> > - Eric
>
> Hi Eric,
>
>
> I've been testing this on a Lenovo Yoga C630 installed to a partition on
> the UFS drive, using a 5.7(ish) kernel with fscrypt/inline-encryption
> and a few patches on top that are still in flux for c630 support. The
> sources I use can be found at
> https://github.com/steev/linux/tree/linux-5.7.y-c630-fscrypt and the
> config I'm using can be found at
> https://dev.gentoo.org/~steev/files/lenovo-yoga-c630-5.7.0-rc7-fs-inline-encryption.config.
>
>
> Everything seems to be working here. I've run the tests you've
> mentioned and haven't seen any issues.
>
Great! Can I add your Tested-by when I send out this patchset again?
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-06-15 18:58 ` Eric Biggers
@ 2020-06-15 19:07 ` Steev Klimaszewski
0 siblings, 0 replies; 20+ messages in thread
From: Steev Klimaszewski @ 2020-06-15 19:07 UTC (permalink / raw)
To: Eric Biggers
Cc: Thara Gopinath, linux-scsi, linux-arm-msm, linux-block,
linux-fscrypt, Alim Akhtar, Andy Gross, Avri Altman,
Barani Muthukumaran, Bjorn Andersson, Can Guo, Elliot Berman,
John Stultz, Satya Tangirala
On 6/15/20 1:58 PM, Eric Biggers wrote:
>
>> Hi Eric,
>>
>>
>> I've been testing this on a Lenovo Yoga C630 installed to a partition on
>> the UFS drive, using a 5.7(ish) kernel with fscrypt/inline-encryption
>> and a few patches on top that are still in flux for c630 support. The
>> sources I use can be found at
>> https://github.com/steev/linux/tree/linux-5.7.y-c630-fscrypt and the
>> config I'm using can be found at
>> https://dev.gentoo.org/~steev/files/lenovo-yoga-c630-5.7.0-rc7-fs-inline-encryption.config.
>>
>>
>> Everything seems to be working here. I've run the tests you've
>> mentioned and haven't seen any issues.
>>
> Great! Can I add your Tested-by when I send out this patchset again?
>
> - Eric
Absolutely. Tested-By: Steev Klimaszewski <steev@kali.org> is preferred
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-07 18:08 ` Eric Biggers
2020-05-08 20:18 ` Steev Klimaszewski
@ 2020-05-29 15:54 ` Thara Gopinath
2020-05-29 17:13 ` Eric Biggers
1 sibling, 1 reply; 20+ messages in thread
From: Thara Gopinath @ 2020-05-29 15:54 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
On 5/7/20 2:08 PM, Eric Biggers wrote:
> On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
>> Hi Thara,
>>
>> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
>>>
>>>
>>> On 5/1/20 12:51 AM, Eric Biggers wrote:
>>>> 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 and runs the upstream
>>>> Linux kernel. 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, both manually using ext4 encryption
>>>> and automatically using a block layer self-test I've written.
>>> Hello Eric,
>>>
>>> I am interested in testing out this series on 845, 855 and if possile on 865
>>> platforms. Can you give me some more details about your testing please.
>>>
>>
>> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
>>
>> A basic manual test would be:
>>
>> 1. Build a kernel with:
>>
>> CONFIG_BLK_INLINE_ENCRYPTION=y
>> CONFIG_FS_ENCRYPTION=y
>> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
>
> Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
Hi Eric,
I tested this manually on db845c, sm8150-mtp and sm8250-mtp.(I added the
dts file entries for 8150 and 8250).
I also ran OsBench test case createfiles[1] on the above platforms.
Following are the results on a non encrypted and encrypted directory on
the same file system(lower the number better)
8250-MTP 8150-MTP DB845
nonencrypt_dir(us) 55.3108954 26.8323124 69.5709552
encrypt_dir(us) 70.0214426 37.5411254 92.3818296
1. https://github.com/mbitsnbites/osbench/blob/master/README.md
--
Warm Regards
Thara
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-29 15:54 ` Thara Gopinath
@ 2020-05-29 17:13 ` Eric Biggers
2020-05-29 21:25 ` Thara Gopinath
0 siblings, 1 reply; 20+ messages in thread
From: Eric Biggers @ 2020-05-29 17:13 UTC (permalink / raw)
To: Thara Gopinath
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
On Fri, May 29, 2020 at 11:54:18AM -0400, Thara Gopinath wrote:
> On 5/7/20 2:08 PM, Eric Biggers wrote:
> > On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
> > > Hi Thara,
> > >
> > > On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
> > > >
> > > >
> > > > On 5/1/20 12:51 AM, Eric Biggers wrote:
> > > > > 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 and runs the upstream
> > > > > Linux kernel. 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, both manually using ext4 encryption
> > > > > and automatically using a block layer self-test I've written.
> > > > Hello Eric,
> > > >
> > > > I am interested in testing out this series on 845, 855 and if possile on 865
> > > > platforms. Can you give me some more details about your testing please.
> > > >
> > >
> > > Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
> > >
> > > A basic manual test would be:
> > >
> > > 1. Build a kernel with:
> > >
> > > CONFIG_BLK_INLINE_ENCRYPTION=y
> > > CONFIG_FS_ENCRYPTION=y
> > > CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
> >
> > Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
>
> Hi Eric,
>
> I tested this manually on db845c, sm8150-mtp and sm8250-mtp.(I added the dts
> file entries for 8150 and 8250).
>
> I also ran OsBench test case createfiles[1] on the above platforms.
> Following are the results on a non encrypted and encrypted directory on the
> same file system(lower the number better)
>
> 8250-MTP 8150-MTP DB845
>
> nonencrypt_dir(us) 55.3108954 26.8323124 69.5709552
> encrypt_dir(us) 70.0214426 37.5411254 92.3818296
>
>
>
> 1. https://github.com/mbitsnbites/osbench/blob/master/README.md
>
Great, thanks for testing.
Note that the benchmark you ran (creating many small files, then deleting them)
mostly tests the performance of filenames encryption and directory operations,
not file contents encryption. Inline encryption is only used for file contents.
In fact, since that benchmark doesn't sync the files before deleting them, there
is no guarantee that any file contents are actually written to disk, and hence
no guarantee that inline encryption got used at all.
It would be more relevant to test the performance of reading/writing file data.
Also, did you try doing any correctness tests? (See what I suggested earlier.)
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-29 17:13 ` Eric Biggers
@ 2020-05-29 21:25 ` Thara Gopinath
2020-05-29 21:38 ` Eric Biggers
0 siblings, 1 reply; 20+ messages in thread
From: Thara Gopinath @ 2020-05-29 21:25 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
On 5/29/20 1:13 PM, Eric Biggers wrote:
> On Fri, May 29, 2020 at 11:54:18AM -0400, Thara Gopinath wrote:
>> On 5/7/20 2:08 PM, Eric Biggers wrote:
>>> On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
>>>> Hi Thara,
>>>>
>>>> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
>>>>>
>>>>>
>>>>> On 5/1/20 12:51 AM, Eric Biggers wrote:
>>>>>> 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 and runs the upstream
>>>>>> Linux kernel. 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, both manually using ext4 encryption
>>>>>> and automatically using a block layer self-test I've written.
>>>>> Hello Eric,
>>>>>
>>>>> I am interested in testing out this series on 845, 855 and if possile on 865
>>>>> platforms. Can you give me some more details about your testing please.
>>>>>
>>>>
>>>> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
>>>>
>>>> A basic manual test would be:
>>>>
>>>> 1. Build a kernel with:
>>>>
>>>> CONFIG_BLK_INLINE_ENCRYPTION=y
>>>> CONFIG_FS_ENCRYPTION=y
>>>> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
>>>
>>> Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
>>
>> Hi Eric,
>>
>> I tested this manually on db845c, sm8150-mtp and sm8250-mtp.(I added the dts
>> file entries for 8150 and 8250).
>>
>> I also ran OsBench test case createfiles[1] on the above platforms.
>> Following are the results on a non encrypted and encrypted directory on the
>> same file system(lower the number better)
>>
>> 8250-MTP 8150-MTP DB845
>>
>> nonencrypt_dir(us) 55.3108954 26.8323124 69.5709552
>> encrypt_dir(us) 70.0214426 37.5411254 92.3818296
>>
>>
>>
>> 1. https://github.com/mbitsnbites/osbench/blob/master/README.md
>>
>
> Great, thanks for testing.
>
> Note that the benchmark you ran (creating many small files, then deleting them)
> mostly tests the performance of filenames encryption and directory operations,
> not file contents encryption. Inline encryption is only used for file contents.
>
> In fact, since that benchmark doesn't sync the files before deleting them, there
> is no guarantee that any file contents are actually written to disk, and hence
> no guarantee that inline encryption got used at all.
Hi Eric,
The results are particularly interesting if you think a sync is not
happening. There should not be any performance regression in this case
between the two directories. I can try some reading/writing performance
tests rather than creating files testing.
>
> It would be more relevant to test the performance of reading/writing file data.
>
> Also, did you try doing any correctness tests? (See what I suggested earlier.)
I did correctness test as part of manual tests by diffing the content of
the copied files and verifying them. I did not run any other tests you
mentioned. Feel free to add my Tested-by in the next version you send out.
>
> - Eric
>
--
Warm Regards
Thara
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
2020-05-29 21:25 ` Thara Gopinath
@ 2020-05-29 21:38 ` Eric Biggers
0 siblings, 0 replies; 20+ messages in thread
From: Eric Biggers @ 2020-05-29 21:38 UTC (permalink / raw)
To: Thara Gopinath
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
On Fri, May 29, 2020 at 05:25:47PM -0400, Thara Gopinath wrote:
> > > Hi Eric,
> > >
> > > I tested this manually on db845c, sm8150-mtp and sm8250-mtp.(I added the dts
> > > file entries for 8150 and 8250).
> > >
> > > I also ran OsBench test case createfiles[1] on the above platforms.
> > > Following are the results on a non encrypted and encrypted directory on the
> > > same file system(lower the number better)
> > >
> > > 8250-MTP 8150-MTP DB845
> > >
> > > nonencrypt_dir(us) 55.3108954 26.8323124 69.5709552
> > > encrypt_dir(us) 70.0214426 37.5411254 92.3818296
> > >
> > >
> > >
> > > 1. https://github.com/mbitsnbites/osbench/blob/master/README.md
> > >
> >
> > Great, thanks for testing.
> >
> > Note that the benchmark you ran (creating many small files, then deleting them)
> > mostly tests the performance of filenames encryption and directory operations,
> > not file contents encryption. Inline encryption is only used for file contents.
> >
> > In fact, since that benchmark doesn't sync the files before deleting them, there
> > is no guarantee that any file contents are actually written to disk, and hence
> > no guarantee that inline encryption got used at all.
>
> Hi Eric,
>
> The results are particularly interesting if you think a sync is not
> happening.
You can check the source code
(https://github.com/mbitsnbites/osbench/blob/master/src/create_files.c).
There's no sync.
> There should not be any performance regression in this case
> between the two directories.
That's not true; the filenames still need to be encrypted. Filenames encryption
happens right away, not later when the pages are written to disk. Contents
encryption works differently.
> I can try some reading/writing performance tests rather than creating files
> testing.
> >
> > It would be more relevant to test the performance of reading/writing file data.
> >
> > Also, did you try doing any correctness tests? (See what I suggested earlier.)
>
> I did correctness test as part of manual tests by diffing the content of the
> copied files and verifying them. I did not run any other tests you
> mentioned. Feel free to add my Tested-by in the next version you send out.
>
Okay, thanks!
- Eric
^ permalink raw reply [flat|nested] 20+ messages in thread