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
