Re: [PATCH v2 0/6] Add TEE based client driver for UEFI Secure Application

On Wed, Jul 22, 2026 at 12:29:11PM +0530, Harshal Dev wrote:
> On Qualcomm SoC based platforms, UEFI stores EFI variables within the
> Replay Protected Memory Block (RPMB) which is only accessible by the
> Qualcomm Trusted Execution Environment (QTEE).

Is it so? I think RPMB is accessible to Linux...

> For Qualcomm platforms without emulated RPMB support, specifically

What is emulated RPMB support? Why is it mentioned here? Which platforms
use emulated RPMB?

> platforms where RPMB is not located within SPI-NOR storage and instead
> located on UFS/EMMC storage, non-volatile EFI variables can only be set via
> a callback request from the UEFI Secure Application to the RPMB service
> running in user-space (within the QTEE supplicant [1]).

Can it be moved to the kernel?

> 
> Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current
> QSEECOM based uefisecapp) does not support callback requests.

How did it work then? I think Windows has been perfectly using QSEECOM
rather than QTEE.

> And on
> certain Qualcomm platforms such as the RB3Gen2, attempts to access the
> QSEECOM interface fail due to lack of support within Qualcomm TEE.

So, I assume, on RB3 Gen2 the QSEECOM doesn't report uefisecapp as
supported. Does it?

> On these platforms, a TEE based uefisecapp client driver is required to:
> 1. Access cached & volatile EFI variables stored in uefisecapp's memory.
> 2. Ensure persistence of non-volatile EFI variables via writes through
> the RPMB service hosted in the QTEE supplicant.
> 
> This series introduces such a uefisecapp TEE client driver for the
> aforementioned Qualcomm platforms which installs efi-var operations _if_
> the QCOMTEE driver registers support for an object-IPC based uefisecapp
> service on the TEE bus during its probe. Only new QTEE firmware versions
> available at [2] provide this support.

What about existing WoA devices?

> 
> Thus, QCOMTEE now maintains a static list of always-available object-IPC
> based secure services exposed by QTEE. These services are implemented either
> within the QTEE kernel or within a pre-loaded Trusted Application (TA)
> usually loaded by the bootloader. The uefisecapp TA is an example of a
> preloaded TA loaded by UEFI. A static list is required since QTEE does not
> yet expose any way to dynamically query and enumerate the services exposed by
> it.

Can it be fixed instead of having static lists? In the end, we can't
guarantee that users update the firmware.

> 
> To facilitate object-IPC interactions from the kernel-space, this
> series also introduces a tee_client_object_invoke_func() to allow
> invocation of TEE objects similar to the existing tee_client_invoke_func()
> API exported by the TEE subsystem which allows invocation of TEE functions.
> Some suporting changes are also introduced to track and handle operations
> for TEE contexts opened from the kernel-space in the back-end QCOM-TEE
> driver.
> 
> Finally and as previously mentioned, access to the object-IPC based uefisecapp
> service is restricted on older QTEE firmware versions. A new QTEE firmware
> release must be picked up from QArtifactory [2] for all upstream supported
> Qualcomm SoCs to enable access to uefisecapp service via the TEE client
> driver.

What about fused devices?

> 
> This patch series has been validated on Kodiak RB3Gen2 platform with UFS
> storage by attempting to read/write EFI variables via the efivar tool [3]
> after mounting the efivarfs filesystem. See [4] for an example.
> 
> Merge Strategy:
> 
> This patch series could either be taken from the OP-TEE tree or the
> QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since
> all except the uefisecapp TEE client driver patch in this series make
> changes relevant to the TEE subsystem. It would be great if the QCOM soc
> tree maintainers can Ack the uefisecapp driver patch.
> 
> [1] https://github.com/qualcomm/minkipc
> [2] https://shorturl.at/zQU07
> [3] https://github.com/rhboot/efivar
> [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_variables_using_efivar_tool.html
> 
> Signed-off-by: Harshal Dev <[email protected]>
> ---
> Changes in v2:
> - Drop using MSB of the object_id to distingush kernel and user object invoke contexts.
> - Introduce enum tee_object_invoke_origin to check the context of object invocation.
> - Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659cbd5d04c@oss.qualcomm.com
> 
> ---
> Amirreza Zarrabi (2):
>       tee: Add kernel client object invoke helper
>       tee: qcomtee: Allow object invokes from kernel clients
> 
> Harshal Dev (4):
>       tee: qcomtee: Track the object invocation context
>       tee: Export uuidv5 generation for TEE backends
>       tee: qcomtee: Add support for registering QTEE services on TEE bus
>       firmware: qcom: Add support for TEE based EFI-var client driver
> 
>  MAINTAINERS                                 |   7 +
>  drivers/firmware/qcom/Kconfig               |  24 ++
>  drivers/firmware/qcom/Makefile              |   1 +
>  drivers/firmware/qcom/qcom_tee_uefisecapp.c | 525 ++++++++++++++++++++++++++++
>  drivers/firmware/qcom/qcom_tee_uefisecapp.h | 120 +++++++

I don't see any changes to the QSEECOM drivers. Is it allowed to use
QSEECOM and QTEE access to uefisecapp at the same time?

>  drivers/tee/qcomtee/call.c                  | 205 ++++++++++-
>  drivers/tee/qcomtee/core.c                  |   9 +-
>  drivers/tee/qcomtee/qcomtee.h               |  12 +
>  drivers/tee/qcomtee/qcomtee_msg.h           |   1 +
>  drivers/tee/qcomtee/qcomtee_object.h        |  16 +-
>  drivers/tee/tee_core.c                      |  24 +-
>  include/linux/tee_core.h                    |  23 +-
>  include/linux/tee_drv.h                     |  18 +-
>  13 files changed, 952 insertions(+), 33 deletions(-)
> ---
> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
> change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014
> 
> Best regards,
> -- 
> Harshal Dev <[email protected]>
> 

-- 
With best wishes
Dmitry