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

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.

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

> +	  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()?


-- 
With best wishes
Dmitry