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 harshal.dev@oss.qualcomm.com

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@vger.kernel.org S: Maintained F: drivers/firmware/qcom/qcom_qseecom_uefisecapp.c +QUALCOMM TEE UEFISECAPP DRIVER +M: Harshal Dev harshal.dev@oss.qualcomm.com +L: linux-arm-msm@vger.kernel.org +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@oss.qualcomm.com M: Sean Tranchetti sean.tranchetti@oss.qualcomm.com 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()?