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

Hello Dmitry,

A gentle reminder. Hopefully we can align on below points and move to
a v3 of this series.

Regards,
Harshal

On 17-08-2026 11:54 am, Harshal Dev wrote:
> Hi Dmitry,
> 
> Many thanks for your engagement and review on this series. I am looking forward
> to your opinions on below comments so we can align on a a v3 of this series.
> 
> Best Regards,
> Harshal
> 
> On 12-08-2026 05:00 pm, Harshal Dev wrote:
>> 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
>>
>>
>>  
>>
>