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

[Eric Biggers <ebiggers@kernel.org>]

Hi Srinivas,

On Tue, Aug 29, 2023 at 06:11:55PM +0100, Srinivas Kandagatla wrote:
> > It's true that Qualcomm based Android devices already use HW-wrapped keys on
> > SoCs earlier than SM8650.  The problem is that the key generation, import, and
> > conversion were added to Android's KeyMint HAL, as a quick way to get the
> > feature out the door when it was needed (so to speak).  Unfortunately this
> 
> There is an attempt in 2021 todo exactly same thing I guess,
> 
> https://patchwork.kernel.org/project/linux-fscrypt/cover/20211206225725.77512-1-quic_gaurkash@quicinc.com/
> 
> If this was the right thing to do they why is the TZ firmware on SoCs after
> 2021 not having support for this ?

That's on Qualcomm.  But my understanding is that it's just taking them several
years to get the TZ changes out due to their branching schedule.  Garauv
submitted the TZ changes in 2021, but apparently SM8550 had already branched at
that point, so SM8650 is the first one that will have it.

Just because it takes Qualcomm a while to get the firmware support for this
feature deployed doesn't mean that it's the wrong approach.

> 
> > coupled this feature unnecessarily to the Android KeyMint and the corresponding
> > (closed source) userspace HAL provided by Qualcomm, which it's not actually
> 
> So how does Andriod kernel upgrades work after applying this patchset on
> platforms like SM8550 or SM8450 or SM8250..or any old platforms.

The same way they did before.  Older devices won't use this new code.

BTW, this is irrelevant for upstream.

> 
> > related to.  I'd guess that Qualcomm's closed source userspace HAL makes SMC
> > calls into Qualcomm's KeyMint TA, but I have no insight into those details.
> > 
> If we have an smcinvoke tee driver we can talk to to this TA.
> 
> > The new SMC calls eliminate the dependency on the Android-specific KeyMint.
> 
> I can see that.
> 
> Am not against adding this new interface, but is this new interface leaving
> a gap for older platforms?
> 
> 
> Is there any other technical reason for moving out from TA based to a smc
> calls?
> 
> And are we doing a quick solution here to fix something

I have very little insight into Qualcomm's old interface, which is tied to the
Android-specific KeyMint and is not known to be usable outside the Android
context or without the closed source userspace HAL from Qualcomm.

I understand that Linux kernel features that are only usable with closed source
userspace libraries are heavily frowned on.  As are features that are tied to
Android and cannot be used on other Linux distros.

If Qualcomm can document the old interface and show that it's usable directly by
the Linux kernel, then we could consider it.  But without that, the new
interface is our only option.

> > 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.

Downstream users who implemented a less well designed version of this feature
can continue to use their existing code.

BTW, I am the person who has gotten stuck maintaining the framework for
HW-wrapped key support in the Android Common Kernels...  So if you're trying to
make things "easier" for me, please don't.  I want to have a properly designed
version of the feature upstream, and then I'll change Android to use that
whenever possible.  That's the only real long-term solution.

- Eric