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

[Harshal Dev <harshal.dev@oss.qualcomm.com>]

Hi Dmitry,

A gentle reminder, do let me know you opinion on my comments here.
I plan to spin a v3 once we're aligned on any open points.

Thanks,
Harshal

On 24-07-2026 02:43 pm, 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.
> 
>>
>>> 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>
>>>
>>
>