Messages in this thread | | | Date | Fri, 2 Sep 2022 12:56:58 +0530 | Subject | Re: [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application | From | Sumit Garg <> |
| |
Hi Maximilian,
On 02/08/22 18:52, Maximilian Luz wrote: > > > On 8/2/22 13:51, Srinivas Kandagatla wrote: >> Hi Maximilian, >> >> On 23/07/2022 23:49, Maximilian Luz wrote: >>> On modern Qualcomm platforms, access to EFI variables is restricted to >>> the secure world / TrustZone, i.e. the Trusted Execution Environment >>> (TrEE or TEE) as Qualcomm seems to call it. To access EFI variables, we >>> therefore need to talk to the UEFI Secure Application (uefisecapp), >>> residing in the TrEE. >>> >>> This series adds support for accessing EFI variables on those >>> platforms. >>> >>> To do this, we first need to add some SCM call functions used to manage >>> and talk to Secure Applications. A very small subset of this interface >>> is added in the second patch (whereas the first one exports the >>> required >>> functions for that). Interface specifications are extracted from [1]. >>> While this does not (yet) support re-entrant SCM calls (including >>> callbacks and listeners), this is enough to talk to the aforementioned >>> uefisecapp on a couple of platforms (I've tested this on a Surface >>> Pro X >>> and heard reports from Lenovo Flex 5G, Lenovo Thinkpad x13s, and Lenovo >>> Yoga C630 devices). >>> >>> The third patch adds a client driver for uefisecapp, installing the >>> respective efivar operations. The application interface has been >>> reverse >>> engineered from the Windows QcTrEE8180.sys driver. >>> >>> Apart from uefisecapp, there are more Secure Applications running that >>> we might want to support in the future. For example, on the Surface Pro >>> X (sc8180x-based), the TPM is also managed via one. >>> >>> I'm not sure whether this should go to drivers/firmware or to >>> drivers/soc/qcom. I've put this into firmware as all of this is >>> essentially an interface to the secure firmware running in the >>> TrustZone >>> (and SCM stuff is handled here already), but please let me know if I >>> should move this. >> >> From what I see so far is that this is adapted from downstream >> qseecom driver, this approach could work for a limited usecases but >> not scalable, as we cannot add drivers for each Qualcomm specific TA >> in kernel. >> This has to be handled in much generic way using Linux TEE framework, >> and let the userspace side deal with TA specific bits. > > I generally agree with the sentiment, however UEFI variables should > IMHO be > handled by the kernel. Moving handling of those to userspace breaks > things like > EFI-based pstore and efivarfs. The latter will in turn break some > user-space > tools (most notably efibootmgr used by e.g. GRUB and I think fwupdmgr > which > needs to set some capsule variables). Ideally, we would find a way to > not break > these, i.e. have them work out-of-the-box. > > A similar argumentation might apply to the TPM app.
See below, there is already an existing TPM app driver [2] in kernel although the app is based on OP-TEE.
> >> AFAIU, Qualcomm is moving away from qseecom interface to new >> smc-invoke interface, most of Qualcomm SoCs starting from SDM660 >> already have support to this. >> >> This interface provides a better abstracted IPC mechanism to talk to >> TA. Most of these TA specific interfaces are packed in closed >> userspace source. >> Having said that QTEE smcinvoke driver can be modeled as a proper TEE >> driver with Userspace driving the TA specific bits using existing tee >> uapis. >> This also brings in other features like loading, Listeners aka >> callbacks, secure memory allocations..etc. >> >> In the past, I have tried to do a prototype of this smcinvoke driver >> as a proper tee driver, incase you are interested patches are at >> https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/log/?h=tracking-qcomlt-qcomtee >> Plan is to discuss with Qualcomm and send it for upstream review. > > Thanks for this information! So as far as I understand it, this is > currently an > interface to user-space only, i.e. does not allow in-kernel drivers > for apps?
The Linux TEE framework already provides an in-kernel interface to TEE as well via TEE bus [1]. There are already multiple kernel drivers [2] [3] [4] [5] [6] [7] using it. So an EFI driver can be an addition to that.
Now coming on to TEE implementations, the drivers I mentioned are based on OP-TEE where devices are queried/enumerated during OP-TEE probe here [8]. So in similar manner QTEE smcinvoke driver should be able to register devices on the TEE bus.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/staging/tee.rst#n56
[2] drivers/char/tpm/tpm_ftpm_tee.c
[3] drivers/char/hw_random/optee-rng.c
[4] drivers/firmware/arm_scmi/optee.c
[5] security/keys/trusted-keys/trusted_tee.c
[6] drivers/firmware/broadcom/tee_bnxt_fw.c
[7] drivers/rtc/rtc-optee.c
[8] drivers/tee/optee/device.c
-Sumit
PS. TBH, I haven't looked into detail workings for the QTEE smcinvoke driver.
> It would be great if this could then be extended to handle (the bare > minimum > of) in-kernel drivers (i.e. only things that the kernel itself needs, > like EFI > variables). Alternatively, I'm happy to hear suggestions on how we not > break > the aforementioned things while moving handling off to userspace. > >> I think its worth exploring if uefisecapp can talk smcinvoke. >> I can ping Qualcomm engineers to see if that is doable. > > I think that would be great! Thanks! > > Regards, > Max >
| |