Re: [PATCH v2 00/10] Hardware wrapped key support for qcom ice and ufs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 30/08/2023 17:12, Eric Biggers wrote:
On Wed, Aug 30, 2023 at 11:00:07AM +0100, Srinivas Kandagatla wrote:

3. We are adding these apis/callbacks in common code without doing any
compatible or SoC checks. Is this going to be a issue if someone tries
fscrypt?

ufs-qcom only declares support for wrapped keys if it's supported.  See patch 5
of this series:

+	if (qcom_ice_hwkm_supported(host->ice))
+		hba->quirks |= UFSHCD_QUIRK_USES_WRAPPED_CRYPTO_KEYS;

That in turn uses:

+bool qcom_ice_hwkm_supported(struct qcom_ice *ice)
+{
+	return (ice->hwkm_version > 0);
+}
+EXPORT_SYMBOL_GPL(qcom_ice_hwkm_supported);

Which in turn comes from the ICE version being >= 3.2.  It does seem a bit
suspicious; it probably should check for both the ICE version and the
availability of QCOM_SCM_ES_GENERATE_ICE_KEY, QCOM_SCM_ES_PREPARE_ICE_KEY, and
QCOM_SCM_ES_IMPORT_ICE_KEY.  Regardless, it sounds like you want it to be
determined by something set in the device tree instead?  I don't think it's been
demonstrated that that's necessary.  If we can detect the hardware capabilities
dynamically, we should do that, right?

I don't mind either way.

It would be perfect if we can dynamically query the TZ version to determine these capabilities.


If not we are left with some way to derive that information either via DT or other means.

--srini

- Eric



[Index of Archives]     [linux Cryptography]     [Asterisk App Development]     [PJ SIP]     [Gnu Gatekeeper]     [IETF Sipping]     [Info Cyrus]     [ALSA User]     [Fedora Linux Users]     [Linux SCTP]     [DCCP]     [Gimp]     [Yosemite News]     [Deep Creek Hot Springs]     [Yosemite Campsites]     [ISDN Cause Codes]

  Powered by Linux