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
