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

[Harshal Dev]

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@xxxxxxxxxxxxxxxx>
>> ---
>> 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@xxxxxxxxxxxxxxxx
>>
>> ---
>> 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@xxxxxxxxxxxxxxxx>
>>
>