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

[Harshal Dev]

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 <harshal.dev@xxxxxxxxxxxxxxxx>
>> ---
>>  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:	linux-arm-msm@xxxxxxxxxxxxxxx
>>  S:	Maintained
>>  F:	drivers/firmware/qcom/qcom_qseecom_uefisecapp.c
>>  
>> +QUALCOMM TEE UEFISECAPP DRIVER
>> +M:	Harshal Dev <harshal.dev@xxxxxxxxxxxxxxxx>
>> +L:	linux-arm-msm@xxxxxxxxxxxxxxx
>> +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 <subash.a.kasiviswanathan@xxxxxxxxxxxxxxxx>
>>  M:	Sean Tranchetti <sean.tranchetti@xxxxxxxxxxxxxxxx>
>> 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.
> 
>> +
>> +static struct qcomtee_uefisec_app uefisec_app;
> 
> Do you need global data? Can it be obtained from other context variables
> using container_of()?
> 
>