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

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
> 
> 
>  
>