Re: [PATCH v2 6/6] firmware: qcom: Add support for TEE based EFI-var client driver

On 24-07-2026 02:44 pm, Harshal Dev wrote:
> Hi Dmitry,
> 
> On 22-07-2026 02:07 pm, Dmitry Baryshkov wrote:
>> On Wed, Jul 22, 2026 at 12:29:17PM +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).
>>>
>>> For Qualcomm platforms without emulated RPMB support, specifically
>>> 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 Trusted Application (TA) to the RPMB
>>> service running in user-space (within the QTEE supplicant).
>>>
>>> Unlike the QCOMTEE driver, the QSEECOM driver (used by the current
>>> uefisecapp client driver) does not support callback requests. And on
>>> certain Qualcomm platforms such as the RB3Gen2, attempts to access the
>>> QSEECOM interface fail due to lack of support within QTEE.
>>> On all such platforms, a TEE based uefisecapp client driver must be used to
>>> access cached/volatile EFI variables within the uefisecapp TA and ensure
>>> persistence of writes to non-volatile EFI variables through the RPMB
>>> service hosted in the QTEE supplicant.
>>>
>>> Add support for a TEE based uefisecapp client driver which installs efivar
>>> operations after obtaining an object reference to the uefisecapp service.
>>> This enables the kernel/user-space to access/modify both volatile EFI vars
>>> stored by the Secure Application (in-memory) and non-volatile ones stored
>>> within RPMB.
>>>
>>> Signed-off-by: Harshal Dev <[email protected]>
>>> ---
>>>  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 +++++++
>>>  5 files changed, 677 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 10d12b51b1f6..e8316007370f 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -22018,6 +22018,13 @@ L:	[email protected]
>>>  S:	Maintained
>>>  F:	drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
>>>  
>>> +QUALCOMM TEE UEFISECAPP DRIVER
>>> +M:	Harshal Dev <[email protected]>
>>> +L:	[email protected]
>>> +S:	Maintained
>>> +F:	drivers/firmware/qcom/qcom_tee_uefisecapp.c
>>> +F:	drivers/firmware/qcom/qcom_tee_uefisecapp.h
>>> +
>>>  QUALCOMM RMNET DRIVER
>>>  M:	Subash Abhinov Kasiviswanathan <[email protected]>
>>>  M:	Sean Tranchetti <[email protected]>
>>> diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
>>> index b477d54b495a..20ce8b58e490 100644
>>> --- a/drivers/firmware/qcom/Kconfig
>>> +++ b/drivers/firmware/qcom/Kconfig
>>> @@ -74,4 +74,28 @@ config QCOM_QSEECOM_UEFISECAPP
>>>  	  Select Y here to provide access to EFI variables on the aforementioned
>>>  	  platforms.
>>>  
>>> +config QCOM_TEE_UEFISECAPP
>>> +	tristate "Qualcomm TEE UEFI Secure App client driver"
>>> +	depends on QCOMTEE
>>> +	depends on EFI
>>> +	depends on !QCOM_QSEECOM_UEFISECAPP
>>
>> Nope. The kernels can be built for multiple platforms. Implement a
>> runtime selection, which uefisecapp client is to be used.
>>
> 
> I agree. I reflected on this yesterday, and in hindsight it feels we do not
> really need to add a !QCOM_QSEECOM_UEFISECAPP. Both of these drivers can co-exist.
> 
> Both drivers attempt to register to the efivar interface via efivar_register(),
> but only one will ever succeed. Since both QCOM_QSEECOM_UEFISECAPP and QCOM_QSEECOM
> are built into the kernel with 'y' the default path will be QSEECOM based when
> both are supported.
> 
> I can drop this 'depends' in v3, and instead add a commit which enables this by
> default with CONFIG_QCOM_TEE_UEFISECAPP=m. Let me know your thoughts. 
>>> +	help
>>> +	  On Qualcomm SoC based platforms without emulated RPMB support,
>>
>> What is emulated RPMB support? How does a user (or a distro maintainer)
>> understand if this needs to be enabled or not?
> 
> Ack. I will try to use simpler terms here to help distro maintainers. If device has
> UFS/eMMC storage, this driver is the only way to access EFI variables within
> RPMB. So it should be set to 'm'.
> 
> If device is SPI-NOR based, this driver will still work. User can decide
> if they want to use this or continue with the old QSEECOM path.
> 
> Regards,
> Harshal
> 
>>
>>> +	  specifically platforms where RPMB is not present 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:
>>> +	  github.com/qualcomm/minkipc). Unlike the QCOMTEE driver, the QSEECOM
>>> +	  driver used by the QSEECOM based uefisecapp does not support callback
>>> +	  requests. And so on these platforms, the TEE based uefisecapp client
>>> +	  driver must be used to ensure persistence of non-volatile EFI variables
>>> +	  via writes through the RPMB service hosted in the QTEE supplicant.
>>> +
>>> +	  This module provides a TEE client driver for uefisecapp, installing efivar
>>> +	  operations to allow the kernel and user-space access to EFI variables.
>>> +
>>> +	  Select m here to provide access to EFI variables on the aforementioned
>>> +	  platforms if your Linux distribution has QTEE supplicant installed and
>>> +	  running.
>>> +
>>>  endmenu
>>> diff --git a/drivers/firmware/qcom/Makefile b/drivers/firmware/qcom/Makefile
>>> index 0be40a1abc13..d780490b2865 100644
>>> --- a/drivers/firmware/qcom/Makefile
>>> +++ b/drivers/firmware/qcom/Makefile
>>> @@ -8,3 +8,4 @@ qcom-scm-objs += qcom_scm.o qcom_scm-smc.o qcom_scm-legacy.o
>>>  obj-$(CONFIG_QCOM_TZMEM)	+= qcom_tzmem.o
>>>  obj-$(CONFIG_QCOM_QSEECOM)	+= qcom_qseecom.o
>>>  obj-$(CONFIG_QCOM_QSEECOM_UEFISECAPP) += qcom_qseecom_uefisecapp.o
>>> +obj-$(CONFIG_QCOM_TEE_UEFISECAPP) += qcom_tee_uefisecapp.o
>>> diff --git a/drivers/firmware/qcom/qcom_tee_uefisecapp.c b/drivers/firmware/qcom/qcom_tee_uefisecapp.c
>>> new file mode 100644
>>> index 000000000000..9a5a6f145a9f
>>> --- /dev/null
>>> +++ b/drivers/firmware/qcom/qcom_tee_uefisecapp.c
>>> @@ -0,0 +1,525 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>>> + */
>>> +
>>> +#include <linux/efi.h>
>>> +#include <linux/tee.h>
>>> +#include <linux/tee_drv.h>
>>> +#include <linux/ucs2_string.h>
>>> +#include "qcom_tee_uefisecapp.h"
>>
>> You are the only user, inline the header here.

Ack. I will expand this header and place its contents in this .c file itself.
I hope this is what you meant by 'inline'.

>>
>>> +
>>> +static struct qcomtee_uefisec_app uefisec_app;
>>
>> Do you need global data? Can it be obtained from other context variables
>> using container_of()?

Actually I really did try to do this, but unfortunately the EFI subsystem's efivars_register()
API called by this driver doesn't provide a way to store a private pointer to a struct like this one.
And so none of the callbacks registered by this driver via qcom_efivar_ops{} can provide
access to this pointer by calling container_of() later. The other EFI drivers have a similar
constraint:
https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/firmware/efi/stmm/tee_stmm_efi.c#L27
https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c#L697

Apologies for missing out on these two comments in the previous reply.

Regards,
Harshal

>>
>>
>