Hi Eric, On 29/08/2023 19:12, Eric Biggers wrote:
These are not unusual questions, what am trying to understand here is below questions for better context, big picture and review/test. At the end of the day we all want to get these features available in upstream.They're also being documented by Qualcomm. So, as this patchset does, they can be used by Linux in the implementation of new ioctls which provide a vendor independent interface to HW-wrapped key generation, import, and conversion. I think the new approach is the only one that is viable outside the Android context. As such, I don't think anyone has any plan to upstream support for HW-wrapped keys for older Qualcomm SoCs that lack the new interface.AFAIU, There are other downstream Qualcomm LE platforms that use wrapped key support with the older interface. What happens to them whey then upgrade the kernel? Does TA interface still continue to work with the changes that went into common drivers (ufs/sd)?This is a strange line of questioning for upstream review, as this feature does not exist upstream. This is the first time it will be supported by upstream Linux, ever. Adding support for this feature does not break anything.
1. How backward compatibility of this wrapped key support. I guess the answer is NO.
2. secondly reasons behind this change. Am still not really convinced with the current technical reasoning to shift from TA based approach to this. But I guess this is all done to dump the closed source userspace thingy. Am hoping that this can be made available to other older SoCs at some point in time.
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?
--srini
Downstream users who implemented a less well designed version of this feature can continue to use their existing code.
|