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

[Harshal Dev]

Hi Dmitry,

On 10-08-2026 12:37 pm, Dmitry Baryshkov wrote:
> On Fri, Jul 24, 2026 at 02:43:42PM +0530, Harshal Dev wrote:
>> 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.
> 
> OK.
> 
>>
>>>
>>>> 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.
> 
> This needs to be explained in the cover letter.
>

Ack. 
>>
>> 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.
> 
> Ok.
> 
>>
>>>
>>>>
>>>> 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
> 
> I have WoA devices without SPI NOR. Windows still can store UEFI
> variables.
>

Ahh, the key point here is 'Windows'. Windows has a separate way of providing
RPMB access via a service in the TrEE driver within the OS:
https://github.com/microsoft/Windows-driver-samples/tree/main/TrEE

However, the Linux QSEECOM driver we have here in upstream does not have that support.
And so without the QCOMTEE + QTEE supplicant combination, we cannot access EFI
variables on these Qualcomm WoA platforms when they boot with upstream Linux.

>> 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.
> 
> Yep. It seems to work under Windows though.
>

As explained above, the mechanism is different for Windows. A different driver
and a different protocol. :)

>>
>>>
>>>> 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
> 
> Does it support QTEE-based uefi variable storage?
>

It does, the QTEE-based uefi variable storage app, i.e. uefisecapp is loaded by
UEFI on RB3Gen2, however, the QSEECOM interface on RB3Gen2 is broken so it misreports
it as 'not supported'. But the app is loaded and available, which is why if you apply
this patch series, you can communicate with it. Just make sure you take the QTEE
release mentioned in this cover letter.

>>>> 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.
> 
> Do extisting commercial devices suppot it? For example, does Lenovo T14s
> support it? Will it continue to work with this patchset in place?

Existing devices like the Lenovo T14s do not have mature QCOMTEE/SMCInvoke support
on QTEE side and new QTEE versions for it are not being rolled out. However, this
QCOMTEE based uefisecapp driver and the QSEECOM based uefisecapp driver can co-exist.
It will not cause any breakage of existing working functionality since the QSEECOM
path can probe and continue as usual.

As per your comments on patch 6 of this series, I plan to enable the QCOMTEE based
uefisecapp as default 'm'. That way we don't need to enable one over the other and
will continue supporting all existing functionality while extending it for devices
with UFS/eMMC storage and running upstream Linux.

Do let me know your opinion on it.

> 
> What about other existing devices? We have WoA devices starting with
> MSM8998. The QSEECOM driver works on them, but, as you mentioned, it
> can't flash updates to the backing storage.
>

Unfortunately, unless we roll out new QTEE firmware versions for devices like MSM8998
with QCOMTEE/SMCInvoke support + access to the Uefisecapp over SMCInvoke protocol,
they cannot be helped with this series.

>> 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.
> 
> Does it work on the CRD?
>

Yes it does, I have validated on Glymur CRD by locally switching it from the current QSEECOM
based uefisecapp to this new QCOMTEE based uefisecapp. This is the QTEE release which
needs to be consumed for it:
https://github.com/qualcomm-linux/meta-qcom/commit/5590c1dc631827624c110df282965b85ef2a2e60 

>>
>> The next planned firmware upgrade for Hamoa will also provide this support for
>> Qualcomm Linux. And similarly, for all other targets being supported upstream.
> 
> So, we are forcing users to upgrade to the new firmware? That doesn't
> sound nice.
>

We have an open ecosystem for all devices supported by the Qualcomm Linux distribution,
users can easily consume new releases (and new QTEE versions) to access new features.
Until now, developers/users of RB3Gen2 or IQ-9075 could not access EFI variables to
develop use-cases such as secure-boot key revocation, but by taking this patch series
as part of a subsequent Qualcomm Linux release, they will be able to.

>>>> 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. 
> 
> It seems you are still rolling out QTEE-based support. In such a case,
> please go back and implement dynamic detection of QTEE services.
> Otherwise it would be a nightmare.
>

We are working on it, but until then there is no overhead involved in maintaining
this static list of services because we don't have to extend/modify this list when
adding support for a new Qualcomm platform upstream. If a particular service from
the list is not implemented/accessible from QTEE we log the event and silently avoid
probing the TEE driver for the service. We also don't add platform specific services
here. So the list doesn't need to be extended on a per-platform basis.

So unlike the QSEECOM driver, we don't have to keep maintaining this list forever
for all new platforms.

>>>> 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
> 
> Will OEMs release new firmware images? What about the devices which are
> already out of the support phase? This whole story rotates about the 'we
> are releasing new firmware with new features' paradigm. However there
> are existing devices in the field, which typically can't be upgraded,
> From your cover letter it seems they can't support UEFI variables
> properly. However they do so in Windows.
>

Yes Dmitry, this series is effectively forward looking. QSEECOM protocol/driver
support is essentially deprecated on QTEE side, no new features added to QTEE support
it, and it also doesn't work on many devices like the RB3Gen2.

For existing devices, if they boot with upstream Linux and have RPMB located on
UFS/eMMC this patch series cannot help them. But the focus of this series is not on the
past, it is on currently supported and future hardware. Every new Qualcomm platform
whose support is being up-streamed or is planned to be up-streamed will have access to
EFI variables via this series.

If someone wants to add support for older Qualcomm devices to access EFI variables
via QSEECOM that patch series will not conflict with this one. Like I said, both
QSEECOM and QCOMTEE based drivers can co-exist.

Regards,
Harshal