lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9892c541ba4e4b5d975faaa4b49c92ba@quicinc.com>
Date: Tue, 18 Jun 2024 00:26:14 +0000
From: "Gaurav Kashyap (QUIC)" <quic_gaurkash@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>,
        Krzysztof Kozlowski
	<krzysztof.kozlowski@...aro.org>,
        "Gaurav Kashyap (QUIC)"
	<quic_gaurkash@...cinc.com>,
        "linux-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>,
        "linux-scsi@...r.kernel.org"
	<linux-scsi@...r.kernel.org>,
        "andersson@...nel.org" <andersson@...nel.org>,
        "ebiggers@...gle.com" <ebiggers@...gle.com>,
        "neil.armstrong@...aro.org"
	<neil.armstrong@...aro.org>,
        srinivas.kandagatla
	<srinivas.kandagatla@...aro.org>,
        "krzysztof.kozlowski+dt@...aro.org"
	<krzysztof.kozlowski+dt@...aro.org>,
        "conor+dt@...nel.org"
	<conor+dt@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        kernel
	<kernel@...cinc.com>,
        "linux-crypto@...r.kernel.org"
	<linux-crypto@...r.kernel.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "Om Prakash Singh (QUIC)"
	<quic_omprsing@...cinc.com>,
        "Bao D. Nguyen (QUIC)"
	<quic_nguyenb@...cinc.com>,
        bartosz.golaszewski
	<bartosz.golaszewski@...aro.org>,
        "ulf.hansson@...aro.org"
	<ulf.hansson@...aro.org>,
        "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
        "martin.petersen@...cle.com" <martin.petersen@...cle.com>,
        "mani@...nel.org"
	<mani@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>
Subject: RE: [PATCH v4 13/15] dt-bindings: crypto: ice: document the hwkm
 property

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@...cinc.com>
> >> Tested-by: Neil Armstrong <neil.armstrong@...aro.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ