linux-kernel - Re: [PATCH v4 13/15] dt-bindings: crypto: ice: document the hwkm property

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dd219c40-33d5-43ff-b0da-16ccf0198bb9@linaro.org>
Date: Thu, 1 Feb 2024 20:13:33 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Gaurav Kashyap <quic_gaurkash@...cinc.com>, linux-arm-msm@...r.kernel.org,
 linux-scsi@...r.kernel.org, andersson@...nel.org, ebiggers@...gle.com,
 neil.armstrong@...aro.org, srinivas.kandagatla@...aro.org,
 krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, robh+dt@...nel.org
Cc: linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
 kernel@...cinc.com, linux-crypto@...r.kernel.org,
 devicetree@...r.kernel.org, quic_omprsing@...cinc.com,
 quic_nguyenb@...cinc.com, bartosz.golaszewski@...aro.org,
 ulf.hansson@...aro.org, jejb@...ux.ibm.com, martin.petersen@...cle.com,
 mani@...nel.org, davem@...emloft.net, herbert@...dor.apana.org.au
Subject: Re: [PATCH v4 13/15] dt-bindings: crypto: ice: document the hwkm
 property

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-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