Hi Eric,
On 29/08/2023 19:12, Eric Biggers wrote:
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.
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.
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.
