| Message ID | 20211206225725.77512-4-quic_gaurkash@quicinc.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add wrapped key support for Qualcomm ICE | expand |
On Mon, Dec 06, 2021 at 02:57:18PM -0800, Gaurav Kashyap wrote: > Storage encryption requires fscrypt deriving a sw secret from As I mentioned on the previous version of this patchset, I think mentions of "fscrypt" should generally be avoided at the driver level. Drivers don't know or care who is using block layer functionality. It's better to think of the sw_secret support as simply one of the requirements for hardware-wrapped keys, alongside the other ones such as support for import_key, prepare_key, etc. > +/** > + * qcom_scm_derive_sw_secret() - Derive SW secret from wrapped encryption key > + * @wrapped_key: the wrapped key used for inline encryption > + * @wrapped_key_size: size of the wrapped key > + * @sw_secret: the secret to be derived which is at most the secret size > + * @secret_size: maximum size of the secret that is derived > + * > + * Derive a SW secret to be used for inline encryption using Qualcomm ICE. The SW secret isn't used for inline encryption. It's actually the opposite; the SW secret is used only for tasks that can't use inline encryption. > + * For wrapped keys, the key needs to be unwrapped, in order to derive a > + * SW secret, which can be done only by the secure EE. So, it makes sense > + * for the secure EE to derive the sw secret and return to the kernel when > + * wrapped keys are used. The second sentence above seems to be saying the same as the first. > + * Return: 0 on success; -errno on failure. > + */ > +int qcom_scm_derive_sw_secret(const u8 *wrapped_key, u32 wrapped_key_size, > + u8 *sw_secret, u32 secret_size) Is @secret_size really the "maximum size of the secret that is derived"? That would imply that a shorter secret might be derived. But if the return value is 0 on success, then there is no way for callers to know what length was derived. Can't the semantics be "derive exactly secret_size bytes"? That would make much more sense. > diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h > index c0475d1c9885..ccd764bdc357 100644 > --- a/include/linux/qcom_scm.h > +++ b/include/linux/qcom_scm.h > @@ -103,6 +103,9 @@ 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 int qcom_scm_derive_sw_secret(const u8 *wrapped_key, > + u32 wrapped_key_size, u8 *sw_secret, > + u32 secret_size); > > extern bool qcom_scm_hdcp_available(void); > extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, > @@ -169,6 +172,9 @@ 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 int qcom_scm_derive_sw_secret(const u8 *wrapped_key, > + u32 wrapped_key_size, u8 *sw_secret, > + u32 secret_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, These "return -ENODEV" stubs don't exist in the latest kernel. Can you make sure that you've developing on top of the latest kernel? It looks like you based this patchset on top of my patchset https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git/log/?h=wrapped-keys-v2. But I had already sent out a newer version of it, based on v5.16-rc1: https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git/log/?h=wrapped-keys-v4. So please make sure you're using the most recent version. - Eric
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index 2ee97bab7440..4a7703846788 100644 --- a/drivers/firmware/qcom_scm.c +++ b/drivers/firmware/qcom_scm.c @@ -1062,6 +1062,79 @@ int qcom_scm_ice_set_key(u32 index, const u8 *key, u32 key_size, } EXPORT_SYMBOL(qcom_scm_ice_set_key); +/** + * qcom_scm_derive_sw_secret() - Derive SW secret from wrapped encryption key + * @wrapped_key: the wrapped key used for inline encryption + * @wrapped_key_size: size of the wrapped key + * @sw_secret: the secret to be derived which is at most the secret size + * @secret_size: maximum size of the secret that is derived + * + * Derive a SW secret to be used for inline encryption using Qualcomm ICE. + * + * For wrapped keys, the key needs to be unwrapped, in order to derive a + * SW secret, which can be done only by the secure EE. So, it makes sense + * for the secure EE to derive the sw secret and return to the kernel when + * wrapped keys are used. + * + * For more information on sw secret, please refer to "Hardware-wrapped keys" + * section of Documentation/block/inline-encryption.rst. + * + * Return: 0 on success; -errno on failure. + */ +int qcom_scm_derive_sw_secret(const u8 *wrapped_key, u32 wrapped_key_size, + u8 *sw_secret, u32 secret_size) +{ + struct qcom_scm_desc desc = { + .svc = QCOM_SCM_SVC_ES, + .cmd = QCOM_SCM_ES_DERIVE_SW_SECRET, + .arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_RO, + QCOM_SCM_VAL, QCOM_SCM_RW, + QCOM_SCM_VAL), + .args[1] = wrapped_key_size, + .args[3] = secret_size, + .owner = ARM_SMCCC_OWNER_SIP, + }; + + void *keybuf, *secretbuf; + dma_addr_t key_phys, secret_phys; + int ret; + + /* + * Like qcom_scm_ice_set_key(), we use dma_alloc_coherent() to properly + * get a physical address, while guaranteeing that we can zeroize the + * key material later using memzero_explicit(). + * + */ + keybuf = dma_alloc_coherent(__scm->dev, wrapped_key_size, &key_phys, + GFP_KERNEL); + if (!keybuf) + return -ENOMEM; + secretbuf = dma_alloc_coherent(__scm->dev, secret_size, &secret_phys, + GFP_KERNEL); + if (!secretbuf) { + ret = -ENOMEM; + goto bail_keybuf; + } + + memcpy(keybuf, wrapped_key, wrapped_key_size); + desc.args[0] = key_phys; + desc.args[2] = secret_phys; + + ret = qcom_scm_call(__scm->dev, &desc, NULL); + if (!ret) + memcpy(sw_secret, secretbuf, secret_size); + + memzero_explicit(secretbuf, secret_size); + dma_free_coherent(__scm->dev, secret_size, secretbuf, secret_phys); + +bail_keybuf: + memzero_explicit(keybuf, wrapped_key_size); + dma_free_coherent(__scm->dev, wrapped_key_size, keybuf, key_phys); + + return ret; +} +EXPORT_SYMBOL(qcom_scm_derive_sw_secret); + /** * 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 d92156ceb3ac..08bb2a4c80db 100644 --- a/drivers/firmware/qcom_scm.h +++ b/drivers/firmware/qcom_scm.h @@ -110,6 +110,7 @@ extern int scm_legacy_call(struct device *dev, const struct qcom_scm_desc *desc, #define QCOM_SCM_SVC_ES 0x10 /* Enterprise Security */ #define QCOM_SCM_ES_INVALIDATE_ICE_KEY 0x03 #define QCOM_SCM_ES_CONFIG_SET_ICE_KEY 0x04 +#define QCOM_SCM_ES_DERIVE_SW_SECRET 0x07 #define QCOM_SCM_SVC_HDCP 0x11 #define QCOM_SCM_HDCP_INVOKE 0x01 diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h index c0475d1c9885..ccd764bdc357 100644 --- a/include/linux/qcom_scm.h +++ b/include/linux/qcom_scm.h @@ -103,6 +103,9 @@ 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 int qcom_scm_derive_sw_secret(const u8 *wrapped_key, + u32 wrapped_key_size, u8 *sw_secret, + u32 secret_size); extern bool qcom_scm_hdcp_available(void); extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, @@ -169,6 +172,9 @@ 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 int qcom_scm_derive_sw_secret(const u8 *wrapped_key, + u32 wrapped_key_size, u8 *sw_secret, + u32 secret_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,
Storage encryption requires fscrypt deriving a sw secret from the keys inserted into the linux keyring. For non-wrapped keys, this can be directly done as keys are in the clear. However, when keys are hardware wrapped, it can be unwrapped by HWKM which is accessible only from Qualcomm Trustzone. Hence, it also makes sense that the software secret is also derived there and returned to the linux kernel for wrapped keys. This can be invoked by using the crypto profile APIs provided by the block layer. Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com> --- drivers/firmware/qcom_scm.c | 73 +++++++++++++++++++++++++++++++++++++ drivers/firmware/qcom_scm.h | 1 + include/linux/qcom_scm.h | 6 +++ 3 files changed, 80 insertions(+)