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
|