mbox series

[v4,00/15] Hardware wrapped key support for qcom ice and ufs

Message ID 20240127232436.2632187-1-quic_gaurkash@quicinc.com
Headers show
Series Hardware wrapped key support for qcom ice and ufs | expand

Message

Gaurav Kashyap (QUIC) Jan. 27, 2024, 11:13 p.m. UTC
The fourth iteration of patches that add support to Qualcomm ICE (Inline Crypto Engine) for hardware wrapped keys using Qualcomm Hardware Key Manager (HWKM)

These patches do the following:
- Address comments from previous versions (https://lore.kernel.org/linux-arm-msm/20231122053817.3401748-1-quic_gaurkash@quicinc.com/)
- Tested on top of Eric's latest fscrypt and block set: https://lore.kernel.org/all/20231104211259.17448-1-ebiggers@kernel.org/
- Rebased and tested on top of Linaro's SHMBridge patches: (https://lkml.org/lkml/2023/11/20/555)

Explanation and use of hardware-wrapped-keys can be found here:
Documentation/block/inline-encryption.rst (https://lore.kernel.org/all/20231104211259.17448-1-ebiggers@kernel.org/)

Testing: 
Test platform: SM8650 MTP

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

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

Steps to test:

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

Flash boot image to shell and run the following commands

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

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

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

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

Merge Strategy:

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

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

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

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

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

Comments

Krzysztof Kozlowski Jan. 29, 2024, 8:18 a.m. UTC | #1
On 28/01/2024 00:14, Gaurav Kashyap wrote:
> When Qualcomm's Inline Crypto Engine (ICE) contains Hardware
> Key Manager (HWKM), and the 'HWKM' mode is enabled, it
> supports wrapped keys. However, this also requires firmware
> support in Trustzone to work correctly, which may not be available
> on all chipsets. In the above scenario, ICE needs to support standard
> keys even though HWKM is integrated from a hardware perspective.
> 
> Introducing this property so that Hardware wrapped key support
> can be enabled/disabled from software based on chipset firmware,
> and not just based on hardware version.
> 
> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
>  .../bindings/crypto/qcom,inline-crypto-engine.yaml     | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> index 09e43157cc71..6415d7be9b73 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> @@ -25,6 +25,16 @@ properties:
>    clocks:
>      maxItems: 1
>  
> +  qcom,ice-use-hwkm:
> +    type: boolean
> +    description:
> +      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
> +      to support wrapped keys. Having this entry helps scenarios where
> +      the ICE hardware supports HWKM, but the Trustzone firmware does
> +      not have the full capability to use this HWKM and support wrapped

How does it help in this scenario? You enable this property, Trustzone
does not support it, so what happens?

Also, which SoCs have incomplete Trustzone support? I expect this to be
a quirk, thus limited to specific SoCs with issues.

Best regards,
Krzysztof
Konrad Dybcio Feb. 1, 2024, 7:13 p.m. UTC | #2
On 29.01.2024 09:18, Krzysztof Kozlowski wrote:
> On 28/01/2024 00:14, Gaurav Kashyap wrote:
>> When Qualcomm's Inline Crypto Engine (ICE) contains Hardware
>> Key Manager (HWKM), and the 'HWKM' mode is enabled, it
>> supports wrapped keys. However, this also requires firmware
>> support in Trustzone to work correctly, which may not be available
>> on all chipsets. In the above scenario, ICE needs to support standard
>> keys even though HWKM is integrated from a hardware perspective.
>>
>> Introducing this property so that Hardware wrapped key support
>> can be enabled/disabled from software based on chipset firmware,
>> and not just based on hardware version.
>>
>> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
>> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>>  .../bindings/crypto/qcom,inline-crypto-engine.yaml     | 10 ++++++++++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> index 09e43157cc71..6415d7be9b73 100644
>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>> @@ -25,6 +25,16 @@ properties:
>>    clocks:
>>      maxItems: 1
>>  
>> +  qcom,ice-use-hwkm:
>> +    type: boolean
>> +    description:
>> +      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
>> +      to support wrapped keys. Having this entry helps scenarios where
>> +      the ICE hardware supports HWKM, but the Trustzone firmware does
>> +      not have the full capability to use this HWKM and support wrapped
> 
> How does it help in this scenario? You enable this property, Trustzone
> does not support it, so what happens?
> 
> Also, which SoCs have incomplete Trustzone support? I expect this to be
> a quirk, thus limited to specific SoCs with issues.

Can we simply evaluate the return value of the secure calls?

Konrad
Gaurav Kashyap (QUIC) June 18, 2024, 12:26 a.m. UTC | #3
Hello Konrad and Krzysztof

On 02/01/2024 11:14, Konrad Dybcio wrote
> On 29.01.2024 09:18, Krzysztof Kozlowski wrote:
> > On 28/01/2024 00:14, Gaurav Kashyap wrote:
> >> When Qualcomm's Inline Crypto Engine (ICE) contains Hardware Key
> >> Manager (HWKM), and the 'HWKM' mode is enabled, it supports wrapped
> >> keys. However, this also requires firmware support in Trustzone to
> >> work correctly, which may not be available on all chipsets. In the
> >> above scenario, ICE needs to support standard keys even though HWKM
> >> is integrated from a hardware perspective.
> >>
> >> Introducing this property so that Hardware wrapped key support can be
> >> enabled/disabled from software based on chipset firmware, and not
> >> just based on hardware version.
> >>
> >> Signed-off-by: Gaurav Kashyap <quic_gaurkash@quicinc.com>
> >> Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
> >> ---
> >>  .../bindings/crypto/qcom,inline-crypto-engine.yaml     | 10 ++++++++++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-
> engine.
> >> yaml
> >> b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-
> engine.
> >> yaml index 09e43157cc71..6415d7be9b73 100644
> >> ---
> >> a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-
> engine.
> >> yaml
> >> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-
> eng
> >> +++ ine.yaml
> >> @@ -25,6 +25,16 @@ properties:
> >>    clocks:
> >>      maxItems: 1
> >>
> >> +  qcom,ice-use-hwkm:
> >> +    type: boolean
> >> +    description:
> >> +      Use the supported Hardware Key Manager (HWKM) in Qualcomm ICE
> >> +      to support wrapped keys. Having this entry helps scenarios where
> >> +      the ICE hardware supports HWKM, but the Trustzone firmware does
> >> +      not have the full capability to use this HWKM and support
> >> + wrapped
> >
> > How does it help in this scenario? You enable this property, Trustzone
> > does not support it, so what happens?
> >
> > Also, which SoCs have incomplete Trustzone support? I expect this to
> > be a quirk, thus limited to specific SoCs with issues.

Apologies for not addressing this earlier, we can perhaps continue this  discussion 
in the new patch thread. I will link to this there.

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

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

> 
> Can we simply evaluate the return value of the secure calls?
> 

This might not work as UFS crypto needs this information much earlier, and based
on that , it would need to register with the keyslot manager (and block crypto), 
on whether wrapped keys are supported.
https://lore.kernel.org/all/20231104211259.17448-2-ebiggers@kernel.org/
 
> Konrad