Hello Srinivas, On Tue, Sep 12, 2023 at 3:07 AM, Srinivas Kandagatla wrote: > Hi Eric/Gaurav, > > Adding more information and some questions to this discussion, > > On 25/08/2023 14:07, Eric Biggers wrote: > > Hi Srinivas, > > > > On Fri, Aug 25, 2023 at 11:19:41AM +0100, Srinivas Kandagatla wrote: > >> > >> On 19/07/2023 18:04, Gaurav Kashyap wrote: > >>> These patches add support to Qualcomm ICE (Inline Crypto Enginr) for > >>> hardware wrapped keys using Qualcomm Hardware Key Manager > (HWKM) and > >>> are made on top of a rebased version Eric Bigger's set of changes > >>> to support wrapped keys in fscrypt and block below: > >>> https://git.kernel.org/pub/scm/fs/fscrypt/linux.git/log/?h=wrapped-k > >>> eys-v7 (The rebased patches are not uploaded here) > >>> > >>> Ref v1 here: > >>> https://lore.kernel.org/linux-scsi/20211206225725.77512-1-quic_gaurk > >>> ash@xxxxxxxxxxx/ > >>> > >>> Explanation and use of hardware-wrapped-keys can be found here: > >>> Documentation/block/inline-encryption.rst > >>> > >>> This patch is organized as follows: > >>> > >>> Patch 1 - Prepares ICE and storage layers (UFS and EMMC) to pass around > wrapped keys. > >>> Patch 2 - Adds a new SCM api to support deriving software secret > >>> when wrapped keys are used Patch 3-4 - Adds support for wrapped keys > >>> in the ICE driver. This includes adding HWKM support Patch 5-6 - > >>> Adds support for wrapped keys in UFS Patch 7-10 - Supports generate, > >>> prepare and import functionality in ICE and UFS > >>> > >>> NOTE: MMC will have similar changes to UFS and will be uploaded in a > different patchset > >>> Patch 3, 4, 8, 10 will have MMC equivalents. > >>> > >>> Testing: > >>> Test platform: SM8550 MTP > >>> Engineering trustzone image is required to test this feature only > >>> for SM8550. For SM8650 onwards, all trustzone changes to support > >>> this will be part of the released images. > >> > >> AFAIU, Prior to these proposed changes in scm, HWKM was done with > >> help of TA(Trusted Application) for generate, import, unwrap ... > functionality. > >> > >> 1. What is the reason for moving this from TA to new smc calls? > >> > >> Is this because of missing smckinvoke support in upstream? > >> > >> How scalable is this approach? Are we going to add new sec sys calls > >> to every interface to TA? > >> > >> 2. How are the older SoCs going to deal with this, given that you are > >> changing drivers that are common across these? > >> > >> Have you tested these patches on any older platforms? > >> > >> What happens if someone want to add support to wrapped keys to this > >> platforms in upstream, How is that going to be handled? > >> > >> As I understand with this, we will endup with two possible solutions > >> over time in upstream. > > > > 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 coupled this feature unnecessarily > > to the Android KeyMint and the corresponding (closed source) userspace > > HAL provided by Qualcomm, which it's not actually 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. > > > > The new SMC calls eliminate the dependency on the Android-specific > KeyMint. > > 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 > > Just bit of history afaiu. > > on Qcom SoCs there are 3 ways to talk to Trusted service/Trusted application. > > 1> Adding SCM calls. This is not scalable solution, imagine we keep > adding new scm calls and static services to the TZ as required and this is going > to bloat up the tz image size. Not only that, new SoCs would need to maintain > backward compatibility, which is not going to happen. > AFAIU this is discouraged in general and Qcom at some point in time will move > away from this.. > > 2> using QSEECOM: This has some scalable issues, which is now replaced > with smcinvoke. > > 3> smcinvoke: This is preferred way to talk to any QTEE service or > application. The issue is that this is based on some downstream UAPI which is > not upstream ready yet. > > IMO, adding a solution that is just going to live for few years is questionable > for upstream. > > Fixing [3] seems to be much scalable solution along with it we will also get > support for this feature in all the Qualcomm platforms. > > Am interested to hear what Gaurav has to say on this. > > > --srini > > What you are referring to is wrapped keys being generated in a Trusted Application (in case of android and some other solutions, keymaster), and eventually being programmed via SCM calls in TZ. And, you are suggesting instead of ioctl->scm call, we should be doing ioctl->smcinvoke->TA What Eric and I are adding here should not be just considered a stopgap, but a path for potential clients to generate and manage wrapped keys without requiring any TA. The TA way will continue to work, and those wrapped keys can be programmed to ICE using fscrypt. Unless, is the suggestion that wrapped keys should always be generated and managed in a trusted application? And then programmed though kernel->SCM call interface? > > HW-wrapped keys for older Qualcomm SoCs that lack the new interface. > > > > - Eric
