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 +++++++ 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(-)
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).
For Qualcomm platforms without emulated RPMB support, specifically
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]).
Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current
QSEECOM based uefisecapp) does not support callback requests. And on
certain Qualcomm platforms such as the RB3Gen2, attempts to access the
QSEECOM interface fail due to lack of support within Qualcomm TEE.
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.
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.
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.
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 <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-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 +++++++
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>
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 <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-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 <harshal.dev@oss.qualcomm.com> > -- With best wishes Dmitry
Hi Dmitry, On 22-07-2026 01:56 pm, Dmitry Baryshkov wrote: > 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... I should have been more descriptive here, RPMB is accessible by Linux but its frames can only be prepared by QTEE. The RPMB key which is one-time programmed into the storage controller to allow authentication of the RPMB frames is generated by and only available to a TEE. So on Qualcomm platforms (and many others platforms with a TEE) Linux can only route the RPMB frames generated by QTEE to the storage, it cannot create and write the RPMB frames itself (it doesn't have access to the key). While it is possible for Linux to generate/program/store this key, on Qualcomm platforms we do not want Linux to do so because we do not trust it. We trust QTEE. I will re-phrase this and make it a bit more clear everywhere. > >> For Qualcomm platforms without emulated RPMB support, specifically > > What is emulated RPMB support? Why is it mentioned here? Which platforms > use emulated RPMB? Emulated RPMB refers to RPMB on a storage which doesn't have its own firmware. Primarily, NAND/NOR storage. Unlike UFS/eMMC storage, NAND/NOR storage does not have a storage controller where we can program the RPMB key to be used by the firmware. So we must 'emulate' RPMB by moving the storage driver within QTEE and making the driver hold/use the key. Qualcomm compute SoCs (Glymur, Hamoa) have RPMB available on SPI-*NOR* storage, and a driver for communicating with it is also available in QTEE. And so, these have 'emulated' RPMB. I will add this detail in an updated cover letter. > >> 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? We have a plan to move the RPMB service to the kernel similar to OPTEE: https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/tee/optee/rpc.c#L449 It is a work in progress. Once this happens, we don't need QTEE supplicant available on the Linux distribution. > >> >> 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. It works because Windows on Arm on Qualcomm has SPI-NOR storage. A driver for which is available within QTEE, and so QTEE does not need to make a callback request to Linux to request RPMB frame routing. However, in case of UFS/eMMC storage the driver only exists in the Linux kernel and so QTEE must make a callback request. And so, if you try to use the QSEECOM driver to write EFI-variables to RPMB on a device with UFS/eMMC storage, it won't work. > >> 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? It doesn't, this API returns -2 if I add RB3 Gen2 in the allow-list for QSEECOM: https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/firmware/qcom/qcom_qseecom.c#L46 > >> 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? New Windows on Arm devices like Hamoa/Glymur work perfectly fine with existing QSEECOM based uefisecapp. But they will also work with this new QCOMTEE based uefisecapp once they upgrade their firmware. I need to double-check but this firmware release for Glymur on Qualcomm Linux is probably carrying the support for QCOMTEE based uefisecapp access: https://github.com/qualcomm-linux/meta-qcom/commit/728251fcbe5113980805ea6c571e33235062ee71 If not, the next release will definitely have it since I have merged support for this in QTEE and talked to the boot firmware release team about this. The next planned firmware upgrade for Hamoa will also provide this support for Qualcomm Linux. And similarly, for all other targets being supported upstream. > >> >> 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. > Unfortunately, no existing QTEE release out there currently has this support. But support for this is currently being added by QTEE team last I checked with them. Once it is available, and a new QTEE firmware release is out there, we will add support for dynamically querying QTEE services in the QCOMTEE driver. >> >> 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? The procedure for updating the firmware on fused devices is slightly different. The firmware images need to be signed by the OEM using the security profile of the chipset before flashing/upgrading them. Security profiles are now public: https://github.com/qualcomm/security-profiles Regards, Harshal > >> >> 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 <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-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 <harshal.dev@oss.qualcomm.com> >> >
© 2016 - 2026 Red Hat, Inc.