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:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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_vari...
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
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-f659...
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 harshal.dev@oss.qualcomm.com