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

[Harshal Dev]

Hi Dmitry,

Gentle Reminder.

Thanks,
Harshal

On 03-08-2026 08:22 pm, Harshal Dev wrote:
> 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@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>
>>>>
>>>
>>
>