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.
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#L44...
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.
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.
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_...
Does it support QTEE-based uefi variable storage?
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?
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?
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.
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/728251fcbe5113980805ea6c5... 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?
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.
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.
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.