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 Secure Application to the RPMB service running in user-space (within the QTEE supplicant [1]).
Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current QSEECOM based uefisecapp) 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 Qualcomm TEE. 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.
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.
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.
This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example.
Merge Strategy:
This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch.
[1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_vari...
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com --- Changes in v2: - Drop using MSB of the object_id to distingush kernel and user object invoke contexts. - Introduce enum tee_object_invoke_origin to check the context of object invocation. - Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659...
--- Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients
Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver
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 +++++++ drivers/tee/qcomtee/call.c | 205 ++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 33 deletions(-) --- base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014
Best regards,
QCOMTEE needs to distinguish between object invocations arriving from kernel clients and user-space clients in order to correctly marshal UBUF parameters and decide whether certain operations should be permitted.
Introduce an enum tee_object_invoke_origin to allow clients to indicate the context of the TEE object invocation, and add a kernel_ctx flag to the QCOMTEE context so the TEE back-end can track it.
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com --- drivers/tee/qcomtee/call.c | 11 ++++++++--- drivers/tee/qcomtee/qcomtee_object.h | 8 ++++++-- drivers/tee/tee_core.c | 3 ++- include/linux/tee_core.h | 8 +++++++- 4 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index 0efc5646242a..03d33b118f6d 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -393,15 +393,20 @@ static int qcomtee_root_object_check(u32 op, struct tee_param *params, */ static int qcomtee_object_invoke(struct tee_context *ctx, struct tee_ioctl_object_invoke_arg *arg, - struct tee_param *params) + struct tee_param *params, + enum tee_object_invoke_origin origin) { struct qcomtee_context_data *ctxdata = ctx->data; struct qcomtee_object *object; + bool kernel_ctx = false; int i, ret, result;
if (qcomtee_params_check(params, arg->num_params)) return -EINVAL;
+ if (origin == TEE_OBJECT_INVOKE_KERNEL) + kernel_ctx = true; + /* First, handle reserved operations: */ if (arg->op == QCOMTEE_MSG_OBJECT_OP_RELEASE) { del_qtee_object(arg->id, ctxdata); @@ -411,7 +416,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx,
/* Otherwise, invoke a QTEE object: */ struct qcomtee_object_invoke_ctx *oic __free(kfree) = - qcomtee_object_invoke_ctx_alloc(ctx); + qcomtee_object_invoke_ctx_alloc(ctx, kernel_ctx); if (!oic) return -ENOMEM;
@@ -648,7 +653,7 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, int result;
struct qcomtee_object_invoke_ctx *oic __free(kfree) = - qcomtee_object_invoke_ctx_alloc(ctx); + qcomtee_object_invoke_ctx_alloc(ctx, true); if (!oic) return;
diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 8b4401ecad48..2528d07e4576 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -146,6 +146,7 @@ static inline int qcomtee_args_len(struct qcomtee_arg *args) * struct qcomtee_object_invoke_ctx - QTEE context for object invocation. * @ctx: TEE context for this invocation. * @flags: flags for the invocation context. + * @kernel_ctx: flag that indicates this context is owned by a kernel client. * @errno: error code for the invocation. * @object: current object invoked in this callback context. * @u: array of arguments for the current invocation (+1 for ending arg). @@ -158,6 +159,7 @@ static inline int qcomtee_args_len(struct qcomtee_arg *args) struct qcomtee_object_invoke_ctx { struct tee_context *ctx; unsigned long flags; + bool kernel_ctx; int errno;
struct qcomtee_object *object; @@ -172,13 +174,15 @@ struct qcomtee_object_invoke_ctx { };
static inline struct qcomtee_object_invoke_ctx * -qcomtee_object_invoke_ctx_alloc(struct tee_context *ctx) +qcomtee_object_invoke_ctx_alloc(struct tee_context *ctx, bool kernel_ctx) { struct qcomtee_object_invoke_ctx *oic;
oic = kzalloc_obj(*oic); - if (oic) + if (oic) { oic->ctx = ctx; + oic->kernel_ctx = kernel_ctx; + } return oic; }
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index ef9642d72672..dba5d4d2d47e 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -706,7 +706,8 @@ static int tee_ioctl_object_invoke(struct tee_context *ctx, goto out; }
- rc = ctx->teedev->desc->ops->object_invoke_func(ctx, &arg, params); + rc = ctx->teedev->desc->ops->object_invoke_func(ctx, &arg, params, + TEE_OBJECT_INVOKE_USERSPACE); if (rc) goto out;
diff --git a/include/linux/tee_core.h b/include/linux/tee_core.h index f993d5118edd..bcb5418d6fdc 100644 --- a/include/linux/tee_core.h +++ b/include/linux/tee_core.h @@ -73,6 +73,11 @@ struct tee_device { struct tee_shm_pool *pool; };
+enum tee_object_invoke_origin { + TEE_OBJECT_INVOKE_USERSPACE, + TEE_OBJECT_INVOKE_KERNEL, +}; + /** * struct tee_driver_ops - driver operations vtable * @get_version: returns version of driver @@ -117,7 +122,8 @@ struct tee_driver_ops { struct tee_param *param); int (*object_invoke_func)(struct tee_context *ctx, struct tee_ioctl_object_invoke_arg *arg, - struct tee_param *param); + struct tee_param *param, + enum tee_object_invoke_origin origin); int (*cancel_req)(struct tee_context *ctx, u32 cancel_id, u32 session); int (*supp_recv)(struct tee_context *ctx, u32 *func, u32 *num_params, struct tee_param *param);
From: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
Kernel clients can open a TEE context and invoke regular TA commands through tee_client_invoke_func(). However, there is currently no equivalent helper for invoking TEE objects.
Add tee_client_object_invoke_func() as a kernel client API for issuing object invocation requests. The helper checks that the backend provides object_invoke_func() before forwarding the request by setting the origin as TEE_OBJECT_INVOKE_KERNEL. This allows TEE backends to support privileged object-based calls from the kernel-space.
Co-developed-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com --- drivers/tee/tee_core.c | 12 ++++++++++++ include/linux/tee_drv.h | 13 +++++++++++++ 2 files changed, 25 insertions(+)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index dba5d4d2d47e..bb418490f3af 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -1410,6 +1410,18 @@ int tee_client_invoke_func(struct tee_context *ctx, } EXPORT_SYMBOL_GPL(tee_client_invoke_func);
+int tee_client_object_invoke_func(struct tee_context *ctx, + struct tee_ioctl_object_invoke_arg *arg, + struct tee_param *param) +{ + if (!ctx->teedev->desc->ops->object_invoke_func) + return -EINVAL; + + return ctx->teedev->desc->ops->object_invoke_func(ctx, arg, param, + TEE_OBJECT_INVOKE_KERNEL); +} +EXPORT_SYMBOL_GPL(tee_client_object_invoke_func); + int tee_client_cancel_req(struct tee_context *ctx, struct tee_ioctl_cancel_arg *arg) { diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index e561a26f537a..ca99c6b747a8 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -283,6 +283,19 @@ int tee_client_invoke_func(struct tee_context *ctx, struct tee_ioctl_invoke_arg *arg, struct tee_param *param);
+/** + * tee_client_object_invoke_func() - Invoke a TEE object from kernel space + * @ctx: TEE Context + * @arg: Invoke arguments, see description of + * struct tee_ioctl_object_invoke_arg + * @param: Parameters for the object invocation + * + * Return: On success, returns 0; on failure, returns < 0. + */ +int tee_client_object_invoke_func(struct tee_context *ctx, + struct tee_ioctl_object_invoke_arg *arg, + struct tee_param *param); + /** * tee_client_cancel_req() - Request cancellation of the previous open-session * or invoke-command operations in a Trusted Application
From: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
QCOMTEE currently treats UBUF parameters as userspace addresses and applies userspace restrictions when invoking the root object. This is not suitable for object invocation requests issued by kernel clients.
Use the kernel_ctx flag to distinguish kernel client requests from userspace requests. For kernel contexts, do not mark UBUF parameters as user addresses, and allow permitted root-object operations to proceed without applying the userspace-only checks.
This allows in-kernel users of tee_client_object_invoke_func() to issue object invocation requests through the qcomtee backend.
Co-developed-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com --- drivers/tee/qcomtee/call.c | 34 +++++++++++++++++++++++----------- drivers/tee/qcomtee/qcomtee_object.h | 5 +++-- include/linux/tee_drv.h | 5 ++++- 3 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index 03d33b118f6d..c1bba5fbfa3e 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -202,7 +202,7 @@ int qcomtee_objref_from_arg(struct tee_param *param, struct qcomtee_arg *arg, */ static int qcomtee_params_to_args(struct qcomtee_arg *u, struct tee_param *params, int num_params, - struct tee_context *ctx) + struct qcomtee_object_invoke_ctx *oic) { int i;
@@ -210,8 +210,14 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, switch (params[i].attr) { case TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT: case TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_OUTPUT: - u[i].flags = QCOMTEE_ARG_FLAGS_UADDR; - u[i].b.uaddr = params[i].u.ubuf.uaddr; + u[i].flags = oic->kernel_ctx ? 0 : + QCOMTEE_ARG_FLAGS_UADDR; + + if (u[i].flags && QCOMTEE_ARG_FLAGS_UADDR) + u[i].b.uaddr = params[i].u.ubuf.uaddr; + else + u[i].b.addr = params[i].u.ubuf.addr; + u[i].b.size = params[i].u.ubuf.size;
if (params[i].attr == @@ -223,7 +229,7 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, break; case TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT: u[i].type = QCOMTEE_ARG_TYPE_IO; - if (qcomtee_objref_to_arg(&u[i], ¶ms[i], ctx)) + if (qcomtee_objref_to_arg(&u[i], ¶ms[i], oic->ctx)) goto out_failed;
break; @@ -270,7 +276,7 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, */ static int qcomtee_params_from_args(struct tee_param *params, struct qcomtee_arg *u, int num_params, - struct tee_context *ctx) + struct qcomtee_object_invoke_ctx *oic) { int i, np;
@@ -288,7 +294,8 @@ static int qcomtee_params_from_args(struct tee_param *params, break; case QCOMTEE_ARG_TYPE_OO: /* TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_OUTPUT */ - if (qcomtee_objref_from_arg(¶ms[np], &u[np], ctx)) + if (qcomtee_objref_from_arg(¶ms[np], &u[np], + oic->ctx)) goto out_failed;
break; @@ -304,7 +311,7 @@ static int qcomtee_params_from_args(struct tee_param *params, /* Undo qcomtee_objref_from_arg(). */ for (i = 0; i < np; i++) { if (params[i].attr == TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_OUTPUT) - qcomtee_context_del_qtee_object(¶ms[i], ctx); + qcomtee_context_del_qtee_object(¶ms[i], oic->ctx); }
/* Release any IO and OO objects not processed. */ @@ -357,7 +364,8 @@ static int qcomtee_params_check(struct tee_param *params, int num_params) }
/* Check if an operation on ROOT_QCOMTEE_OBJECT from userspace is permitted. */ -static int qcomtee_root_object_check(u32 op, struct tee_param *params, +static int qcomtee_root_object_check(struct qcomtee_object_invoke_ctx *oic, + u32 op, struct tee_param *params, int num_params) { /* Some privileged operations recognized by QTEE. */ @@ -366,6 +374,9 @@ static int qcomtee_root_object_check(u32 op, struct tee_param *params, op == QCOMTEE_ROOT_OP_ADCI_SHUTDOWN) return -EINVAL;
+ if (oic->kernel_ctx) + return 0; + /* * QCOMTEE_ROOT_OP_REG_WITH_CREDENTIALS is to register with QTEE * by passing a credential object as input OBJREF. TEE_OBJREF_NULL as a @@ -429,7 +440,8 @@ static int qcomtee_object_invoke(struct tee_context *ctx, /* Get an object to invoke. */ if (arg->id == TEE_OBJREF_NULL) { /* Use ROOT if TEE_OBJREF_NULL is invoked. */ - if (qcomtee_root_object_check(arg->op, params, arg->num_params)) + if (qcomtee_root_object_check(oic, arg->op, params, + arg->num_params)) return -EINVAL;
object = ROOT_QCOMTEE_OBJECT; @@ -437,7 +449,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx, return -EINVAL; }
- ret = qcomtee_params_to_args(u, params, arg->num_params, ctx); + ret = qcomtee_params_to_args(u, params, arg->num_params, oic); if (ret) goto out;
@@ -455,7 +467,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx,
if (!result) { /* Assume service is UNAVAIL if unable to process the result. */ - if (qcomtee_params_from_args(params, u, arg->num_params, ctx)) + if (qcomtee_params_from_args(params, u, arg->num_params, oic)) result = QCOMTEE_MSG_ERROR_UNAVAIL; } else { /* diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 2528d07e4576..7bd6e23b038c 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -112,8 +112,9 @@ struct qcomtee_buffer { * @b: address and size if the type of argument is a buffer. * @o: object instance if the type of argument is an object. * - * &qcomtee_arg.flags only accepts %QCOMTEE_ARG_FLAGS_UADDR for now, which - * states that &qcomtee_arg.b contains a userspace address in uaddr. ++ * If %QCOMTEE_ARG_FLAGS_UADDR is set in &qcomtee_arg.flags then it implies ++ * that &qcomtee_arg.b contains a userspace address in uaddr. ++ * Otherwise, &qcomtee_arg.b contains a kernel address in addr. */ struct qcomtee_arg { enum qcomtee_arg_type type; diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index ca99c6b747a8..71d0536db60e 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -83,7 +83,10 @@ struct tee_param_memref { };
struct tee_param_ubuf { - void __user *uaddr; + union { + void *addr; + void __user *uaddr; + }; size_t size; };
Hi Harshal,
On 7/22/2026 4:59 PM, Harshal Dev wrote:
From: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
QCOMTEE currently treats UBUF parameters as userspace addresses and applies userspace restrictions when invoking the root object. This is not suitable for object invocation requests issued by kernel clients.
Use the kernel_ctx flag to distinguish kernel client requests from userspace requests. For kernel contexts, do not mark UBUF parameters as user addresses, and allow permitted root-object operations to proceed without applying the userspace-only checks.
This allows in-kernel users of tee_client_object_invoke_func() to issue object invocation requests through the qcomtee backend.
Co-developed-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
drivers/tee/qcomtee/call.c | 34 +++++++++++++++++++++++----------- drivers/tee/qcomtee/qcomtee_object.h | 5 +++-- include/linux/tee_drv.h | 5 ++++- 3 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index 03d33b118f6d..c1bba5fbfa3e 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -202,7 +202,7 @@ int qcomtee_objref_from_arg(struct tee_param *param, struct qcomtee_arg *arg, */ static int qcomtee_params_to_args(struct qcomtee_arg *u, struct tee_param *params, int num_params,
struct tee_context *ctx)
struct qcomtee_object_invoke_ctx *oic){ int i; @@ -210,8 +210,14 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, switch (params[i].attr) { case TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT: case TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_OUTPUT:
u[i].flags = QCOMTEE_ARG_FLAGS_UADDR;u[i].b.uaddr = params[i].u.ubuf.uaddr;
u[i].flags = oic->kernel_ctx ? 0 :QCOMTEE_ARG_FLAGS_UADDR;if (u[i].flags && QCOMTEE_ARG_FLAGS_UADDR)u[i].b.uaddr = params[i].u.ubuf.uaddr;elseu[i].b.addr = params[i].u.ubuf.addr;
it is & not &&. Rather than ?:, can you have single if and update both flags and addr/uaddr.
- Amir
u[i].b.size = params[i].u.ubuf.size;if (params[i].attr == @@ -223,7 +229,7 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, break; case TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT: u[i].type = QCOMTEE_ARG_TYPE_IO;
if (qcomtee_objref_to_arg(&u[i], ¶ms[i], ctx))
if (qcomtee_objref_to_arg(&u[i], ¶ms[i], oic->ctx)) goto out_failed;break; @@ -270,7 +276,7 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, */ static int qcomtee_params_from_args(struct tee_param *params, struct qcomtee_arg *u, int num_params,
struct tee_context *ctx)
struct qcomtee_object_invoke_ctx *oic){ int i, np; @@ -288,7 +294,8 @@ static int qcomtee_params_from_args(struct tee_param *params, break; case QCOMTEE_ARG_TYPE_OO: /* TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_OUTPUT */
if (qcomtee_objref_from_arg(¶ms[np], &u[np], ctx))
if (qcomtee_objref_from_arg(¶ms[np], &u[np],oic->ctx)) goto out_failed;break; @@ -304,7 +311,7 @@ static int qcomtee_params_from_args(struct tee_param *params, /* Undo qcomtee_objref_from_arg(). */ for (i = 0; i < np; i++) { if (params[i].attr == TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_OUTPUT)
qcomtee_context_del_qtee_object(¶ms[i], ctx);
qcomtee_context_del_qtee_object(¶ms[i], oic->ctx);/* Release any IO and OO objects not processed. */ @@ -357,7 +364,8 @@ static int qcomtee_params_check(struct tee_param *params, int num_params) } /* Check if an operation on ROOT_QCOMTEE_OBJECT from userspace is permitted. */ -static int qcomtee_root_object_check(u32 op, struct tee_param *params, +static int qcomtee_root_object_check(struct qcomtee_object_invoke_ctx *oic,
u32 op, struct tee_param *params, int num_params){ /* Some privileged operations recognized by QTEE. */ @@ -366,6 +374,9 @@ static int qcomtee_root_object_check(u32 op, struct tee_param *params, op == QCOMTEE_ROOT_OP_ADCI_SHUTDOWN) return -EINVAL;
- if (oic->kernel_ctx)
return 0;- /*
- QCOMTEE_ROOT_OP_REG_WITH_CREDENTIALS is to register with QTEE
- by passing a credential object as input OBJREF. TEE_OBJREF_NULL as a
@@ -429,7 +440,8 @@ static int qcomtee_object_invoke(struct tee_context *ctx, /* Get an object to invoke. */ if (arg->id == TEE_OBJREF_NULL) { /* Use ROOT if TEE_OBJREF_NULL is invoked. */
if (qcomtee_root_object_check(arg->op, params, arg->num_params))
if (qcomtee_root_object_check(oic, arg->op, params,arg->num_params)) return -EINVAL;object = ROOT_QCOMTEE_OBJECT; @@ -437,7 +449,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx, return -EINVAL; }
- ret = qcomtee_params_to_args(u, params, arg->num_params, ctx);
- ret = qcomtee_params_to_args(u, params, arg->num_params, oic); if (ret) goto out;
@@ -455,7 +467,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx, if (!result) { /* Assume service is UNAVAIL if unable to process the result. */
if (qcomtee_params_from_args(params, u, arg->num_params, ctx))
if (qcomtee_params_from_args(params, u, arg->num_params, oic)) result = QCOMTEE_MSG_ERROR_UNAVAIL;diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 2528d07e4576..7bd6e23b038c 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -112,8 +112,9 @@ struct qcomtee_buffer {
- @b: address and size if the type of argument is a buffer.
- @o: object instance if the type of argument is an object.
- &qcomtee_arg.flags only accepts %QCOMTEE_ARG_FLAGS_UADDR for now, which
- states that &qcomtee_arg.b contains a userspace address in uaddr.
++ * If %QCOMTEE_ARG_FLAGS_UADDR is set in &qcomtee_arg.flags then it implies ++ * that &qcomtee_arg.b contains a userspace address in uaddr. ++ * Otherwise, &qcomtee_arg.b contains a kernel address in addr. */ struct qcomtee_arg { enum qcomtee_arg_type type; diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index ca99c6b747a8..71d0536db60e 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -83,7 +83,10 @@ struct tee_param_memref { }; struct tee_param_ubuf {
- void __user *uaddr;
- union {
void *addr;void __user *uaddr;- }; size_t size;
};
Hi Amir,
On 29-07-2026 12:36 pm, Amirreza Zarrabi wrote:
Hi Harshal,
On 7/22/2026 4:59 PM, Harshal Dev wrote:
From: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
QCOMTEE currently treats UBUF parameters as userspace addresses and applies userspace restrictions when invoking the root object. This is not suitable for object invocation requests issued by kernel clients.
Use the kernel_ctx flag to distinguish kernel client requests from userspace requests. For kernel contexts, do not mark UBUF parameters as user addresses, and allow permitted root-object operations to proceed without applying the userspace-only checks.
This allows in-kernel users of tee_client_object_invoke_func() to issue object invocation requests through the qcomtee backend.
Co-developed-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com Signed-off-by: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
drivers/tee/qcomtee/call.c | 34 +++++++++++++++++++++++----------- drivers/tee/qcomtee/qcomtee_object.h | 5 +++-- include/linux/tee_drv.h | 5 ++++- 3 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index 03d33b118f6d..c1bba5fbfa3e 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -202,7 +202,7 @@ int qcomtee_objref_from_arg(struct tee_param *param, struct qcomtee_arg *arg, */ static int qcomtee_params_to_args(struct qcomtee_arg *u, struct tee_param *params, int num_params,
struct tee_context *ctx)
struct qcomtee_object_invoke_ctx *oic){ int i; @@ -210,8 +210,14 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, switch (params[i].attr) { case TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT: case TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_OUTPUT:
u[i].flags = QCOMTEE_ARG_FLAGS_UADDR;u[i].b.uaddr = params[i].u.ubuf.uaddr;
u[i].flags = oic->kernel_ctx ? 0 :QCOMTEE_ARG_FLAGS_UADDR;if (u[i].flags && QCOMTEE_ARG_FLAGS_UADDR)u[i].b.uaddr = params[i].u.ubuf.uaddr;elseu[i].b.addr = params[i].u.ubuf.addr;it is & not &&. Rather than ?:, can you have single if and update both flags and addr/uaddr.
Whoops, thank you for catching this. Ack, I will make this change.
Regards, Harshal
- Amir
u[i].b.size = params[i].u.ubuf.size;if (params[i].attr == @@ -223,7 +229,7 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, break; case TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT: u[i].type = QCOMTEE_ARG_TYPE_IO;
if (qcomtee_objref_to_arg(&u[i], ¶ms[i], ctx))
if (qcomtee_objref_to_arg(&u[i], ¶ms[i], oic->ctx)) goto out_failed;break; @@ -270,7 +276,7 @@ static int qcomtee_params_to_args(struct qcomtee_arg *u, */ static int qcomtee_params_from_args(struct tee_param *params, struct qcomtee_arg *u, int num_params,
struct tee_context *ctx)
struct qcomtee_object_invoke_ctx *oic){ int i, np; @@ -288,7 +294,8 @@ static int qcomtee_params_from_args(struct tee_param *params, break; case QCOMTEE_ARG_TYPE_OO: /* TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_OUTPUT */
if (qcomtee_objref_from_arg(¶ms[np], &u[np], ctx))
if (qcomtee_objref_from_arg(¶ms[np], &u[np],oic->ctx)) goto out_failed;break; @@ -304,7 +311,7 @@ static int qcomtee_params_from_args(struct tee_param *params, /* Undo qcomtee_objref_from_arg(). */ for (i = 0; i < np; i++) { if (params[i].attr == TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_OUTPUT)
qcomtee_context_del_qtee_object(¶ms[i], ctx);
qcomtee_context_del_qtee_object(¶ms[i], oic->ctx);/* Release any IO and OO objects not processed. */ @@ -357,7 +364,8 @@ static int qcomtee_params_check(struct tee_param *params, int num_params) } /* Check if an operation on ROOT_QCOMTEE_OBJECT from userspace is permitted. */ -static int qcomtee_root_object_check(u32 op, struct tee_param *params, +static int qcomtee_root_object_check(struct qcomtee_object_invoke_ctx *oic,
u32 op, struct tee_param *params, int num_params){ /* Some privileged operations recognized by QTEE. */ @@ -366,6 +374,9 @@ static int qcomtee_root_object_check(u32 op, struct tee_param *params, op == QCOMTEE_ROOT_OP_ADCI_SHUTDOWN) return -EINVAL;
- if (oic->kernel_ctx)
return 0;- /*
- QCOMTEE_ROOT_OP_REG_WITH_CREDENTIALS is to register with QTEE
- by passing a credential object as input OBJREF. TEE_OBJREF_NULL as a
@@ -429,7 +440,8 @@ static int qcomtee_object_invoke(struct tee_context *ctx, /* Get an object to invoke. */ if (arg->id == TEE_OBJREF_NULL) { /* Use ROOT if TEE_OBJREF_NULL is invoked. */
if (qcomtee_root_object_check(arg->op, params, arg->num_params))
if (qcomtee_root_object_check(oic, arg->op, params,arg->num_params)) return -EINVAL;object = ROOT_QCOMTEE_OBJECT; @@ -437,7 +449,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx, return -EINVAL; }
- ret = qcomtee_params_to_args(u, params, arg->num_params, ctx);
- ret = qcomtee_params_to_args(u, params, arg->num_params, oic); if (ret) goto out;
@@ -455,7 +467,7 @@ static int qcomtee_object_invoke(struct tee_context *ctx, if (!result) { /* Assume service is UNAVAIL if unable to process the result. */
if (qcomtee_params_from_args(params, u, arg->num_params, ctx))
if (qcomtee_params_from_args(params, u, arg->num_params, oic)) result = QCOMTEE_MSG_ERROR_UNAVAIL;diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 2528d07e4576..7bd6e23b038c 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -112,8 +112,9 @@ struct qcomtee_buffer {
- @b: address and size if the type of argument is a buffer.
- @o: object instance if the type of argument is an object.
- &qcomtee_arg.flags only accepts %QCOMTEE_ARG_FLAGS_UADDR for now, which
- states that &qcomtee_arg.b contains a userspace address in uaddr.
++ * If %QCOMTEE_ARG_FLAGS_UADDR is set in &qcomtee_arg.flags then it implies ++ * that &qcomtee_arg.b contains a userspace address in uaddr. ++ * Otherwise, &qcomtee_arg.b contains a kernel address in addr. */ struct qcomtee_arg { enum qcomtee_arg_type type; diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h index ca99c6b747a8..71d0536db60e 100644 --- a/include/linux/tee_drv.h +++ b/include/linux/tee_drv.h @@ -83,7 +83,10 @@ struct tee_param_memref { }; struct tee_param_ubuf {
- void __user *uaddr;
- union {
void *addr;void __user *uaddr;- }; size_t size;
};
Export the uuidv5() function defined in the TEE core to all TEE backends. This enables the TEE backend drivers to generate a UUID for identifying and registering their secure services on the TEE bus.
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com --- drivers/tee/tee_core.c | 9 +++++---- include/linux/tee_core.h | 15 +++++++++++++++ 2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index bb418490f3af..df88727b3680 100644 --- a/drivers/tee/tee_core.c +++ b/drivers/tee/tee_core.c @@ -135,7 +135,7 @@ static int tee_release(struct inode *inode, struct file *filp) }
/** - * uuid_v5() - Calculate UUIDv5 + * tee_generate_uuid_v5() - Calculate UUIDv5 * @uuid: Resulting UUID * @ns: Name space ID for UUIDv5 function * @name: Name for UUIDv5 function @@ -146,8 +146,8 @@ static int tee_release(struct inode *inode, struct file *filp) * This implements section (for SHA-1): * 4.3. Algorithm for Creating a Name-Based UUID */ -static void uuid_v5(uuid_t *uuid, const uuid_t *ns, const void *name, - size_t size) +void tee_generate_uuid_v5(uuid_t *uuid, const uuid_t *ns, const void *name, + size_t size) { unsigned char hash[SHA1_DIGEST_SIZE]; struct sha1_ctx ctx; @@ -163,6 +163,7 @@ static void uuid_v5(uuid_t *uuid, const uuid_t *ns, const void *name, uuid->b[6] = (hash[6] & 0x0F) | 0x50; uuid->b[8] = (hash[8] & 0x3F) | 0x80; } +EXPORT_SYMBOL_GPL(tee_generate_uuid_v5);
int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, const u8 connection_data[TEE_IOCTL_UUID_LEN]) @@ -228,7 +229,7 @@ int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, goto out_free_name; }
- uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); + tee_generate_uuid_v5(uuid, &tee_client_uuid_ns, name, name_len); out_free_name: kfree(name);
diff --git a/include/linux/tee_core.h b/include/linux/tee_core.h index bcb5418d6fdc..a3f4f88b8423 100644 --- a/include/linux/tee_core.h +++ b/include/linux/tee_core.h @@ -272,6 +272,21 @@ void tee_device_set_dev_groups(struct tee_device *teedev, int tee_session_calc_client_uuid(uuid_t *uuid, u32 connection_method, const u8 connection_data[TEE_IOCTL_UUID_LEN]);
+/** + * tee_generate_uuid_v5() - Calculate UUIDv5 + * @uuid: Resulting UUID + * @ns: Name space ID for UUIDv5 function + * @name: Name for UUIDv5 function + * @size: Size of name + * + * UUIDv5 is specific in RFC 4122. + * + * This implements section (for SHA-1): + * 4.3. Algorithm for Creating a Name-Based UUID + */ +void tee_generate_uuid_v5(uuid_t *uuid, const uuid_t *ns, const void *name, + size_t size); + /** * struct tee_shm_pool - shared memory pool * @ops: operations
QTEE exposes certain secure services implemented either within the QTEE kernel or via pre-loaded Trusted Applications (TAs). Such always-available services can be readily accessed by TEE client drivers via QTEE's object-IPC protocol if the service is registered as a device on the TEE bus.
One such service is the EFI-variables service, implemented by the uefisecapp TA which enables kernel clients to access EFI variables at runtime.
Maintain a static list of such always-available secure services and add support for the QCOMTEE driver to register these services as devices on the TEE bus during probe.
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com --- drivers/tee/qcomtee/call.c | 160 ++++++++++++++++++++++++++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 +++ drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 3 +- 5 files changed, 177 insertions(+), 8 deletions(-)
diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index c1bba5fbfa3e..e909955e6b21 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -662,7 +662,7 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, { struct qcomtee_object *client_env, *service; struct qcomtee_arg u[3] = { 0 }; - int result; + int result, error = 0;
struct qcomtee_object_invoke_ctx *oic __free(kfree) = qcomtee_object_invoke_ctx_alloc(ctx, true); @@ -675,9 +675,13 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id,
/* Get ''FeatureVersions Service'' object. */ service = qcomtee_object_get_service(oic, client_env, - QCOMTEE_FEATURE_VER_UID); - if (service == NULL_QCOMTEE_OBJECT) + QCOMTEE_FEATURE_VER_UID, + &error); + if (service == NULL_QCOMTEE_OBJECT) { + if (error) + pr_err("Failed to get service! error: %d\n", error); goto out_failed; + }
/* IB: Feature to query. */ u[0].b.addr = &id; @@ -697,6 +701,153 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, qcomtee_object_put(client_env); }
+/** + * is_qcomtee_service_available() - Check if the QTEE service identified by the UID + * is available + * @ctx: TEE context. + * @uid: 32-bit UID of the service. + * + * Returns true if the service exists and is available. + * Returns false if a service is not exposed by QTEE. + */ +static bool is_qcomtee_service_available(struct tee_context *ctx, u32 uid) +{ + struct qcomtee_object *client_env; + struct qcomtee_object *service; + int error = 0; + bool ret = false; + + struct qcomtee_object_invoke_ctx *oic __free(kfree) = + qcomtee_object_invoke_ctx_alloc(ctx, true); + if (!oic) + return ret; + + client_env = qcomtee_object_get_client_env(oic); + if (client_env == NULL_QCOMTEE_OBJECT) + return ret; + + /* Get service object corresponding to the uid. */ + service = qcomtee_object_get_service(oic, client_env, uid, &error); + if (service != NULL_QCOMTEE_OBJECT) { + qcomtee_object_put(service); + ret = true; + } + + /* When we fail to get the service, QTEE provides the reason. */ + if (error) + pr_err("Failed to get service! error: %d\n", error); + + qcomtee_object_put(client_env); + return ret; +} + +/* + * QTEE Service UUID name space identifier + * + * A random UUID that is allocated as a name space identifier for forming UUID's + * representing secure services exposed by QTEE. + */ +static const uuid_t qtee_service_uuid_ns = UUID_INIT(0xe1b48857, 0x6154, 0x49f9, + 0x93, 0x4e, 0xa2, 0xf2, + 0x0a, 0xba, 0x98, 0x42); + +static const struct qtee_service qtee_services[] = { + { "qcom.tz.uefisecapp", + QCOMTEE_UEFI_SEC_UID } +}; + +static void qtee_release_service(struct device *dev) +{ + struct tee_client_device *qtee_service = to_tee_client_device(dev); + + kfree(qtee_service); +} + +/** + * qtee_enumerate_service() - Enumerate a given QTEE service and register + * it on the TEE bus as a TEE client device + * @ctx: TEE context. + * @service_uuid: UUID of the service to be registered on the TEE bus. + * @uid: 32-bit UID used by QTEE to identify the service. + * + * Returns 0 on success and < 0 on failure. + */ +static int qtee_enumerate_service(struct tee_context *ctx, const char *service_name, + const u32 uid) +{ + struct tee_client_device *qtee_service; + uuid_t service_uuid; + int rc; + + if (!is_qcomtee_service_available(ctx, uid)) + return -ENXIO; + + tee_generate_uuid_v5(&service_uuid, &qtee_service_uuid_ns, service_name, + strlen(service_name)); + + qtee_service = kzalloc_obj(*qtee_service); + if (!qtee_service) + return -ENOMEM; + + qtee_service->dev.bus = &tee_bus_type; + qtee_service->dev.release = qtee_release_service; + if (dev_set_name(&qtee_service->dev, "qtee-svc-%pUb", &service_uuid)) { + kfree(qtee_service); + return -ENOMEM; + } + uuid_copy(&qtee_service->id.uuid, &service_uuid); + + rc = device_register(&qtee_service->dev); + if (rc) { + pr_err("QTEE service registration failed, err: %d\n", rc); + put_device(&qtee_service->dev); + kfree(qtee_service); + return rc; + } + + return 0; +} + +/** + * qtee_enumerate_services() - Enumerate all the secure services exposed by QTEE + * from the static 'qtee_services' list and register them on the TEE bus as + * TEE client devices. + * + * Not all versions of QTEE support a given service. Hence, we try to + * enumerate as many services from the 'qtee_services' list as possible. + * Not being able to enumerate a service shouldn't cause the driver probe + * to fail since none of the services in the list are mandatory for + * establishing communication with QTEE. + * @ctx: TEE context. + */ +static void qtee_enumerate_services(struct tee_context *ctx) +{ + int rc; + u32 idx; + + for (idx = 0; idx < ARRAY_SIZE(qtee_services); idx++) { + rc = qtee_enumerate_service(ctx, qtee_services[idx].name, + qtee_services[idx].uid); + if (rc == -ENXIO) + pr_err("QTEE does not implement service %d.\n", + qtee_services[idx].uid); + } +} + +static int qtee_unregister_service(struct device *dev, void *data) +{ + if (!strncmp(dev_name(dev), "qtee-svc", strlen("qtee-svc"))) + device_unregister(dev); + + return 0; +} + +static void qtee_unregister_services(void) +{ + bus_for_each_dev(&tee_bus_type, NULL, NULL, + qtee_unregister_service); +} + static const struct tee_driver_ops qcomtee_ops = { .get_version = qcomtee_get_version, .open = qcomtee_open, @@ -778,6 +929,8 @@ static int qcomtee_probe(struct platform_device *pdev) QTEE_VERSION_GET_MINOR(qcomtee->qtee_version), QTEE_VERSION_GET_PATCH(qcomtee->qtee_version));
+ qtee_enumerate_services(qcomtee->ctx); + return 0;
err_dest_wq: @@ -807,6 +960,7 @@ static void qcomtee_remove(struct platform_device *pdev) { struct qcomtee *qcomtee = platform_get_drvdata(pdev);
+ qtee_unregister_services(); teedev_close_context(qcomtee->ctx); /* Wait for RELEASE operations to be processed for QTEE objects. */ tee_device_unregister(qcomtee->teedev); diff --git a/drivers/tee/qcomtee/core.c b/drivers/tee/qcomtee/core.c index b1cb50e434f0..4e39e867c3e9 100644 --- a/drivers/tee/qcomtee/core.c +++ b/drivers/tee/qcomtee/core.c @@ -896,19 +896,20 @@ qcomtee_object_get_client_env(struct qcomtee_object_invoke_ctx *oic)
struct qcomtee_object * qcomtee_object_get_service(struct qcomtee_object_invoke_ctx *oic, - struct qcomtee_object *client_env, u32 uid) + struct qcomtee_object *client_env, u32 uid, + int *result) { struct qcomtee_arg u[3] = { 0 }; - int ret, result; + int ret;
u[0].b.addr = &uid; u[0].b.size = sizeof(uid); u[0].type = QCOMTEE_ARG_TYPE_IB; u[1].type = QCOMTEE_ARG_TYPE_OO; ret = qcomtee_object_do_invoke(oic, client_env, QCOMTEE_CLIENT_ENV_OPEN, - u, &result); + u, result);
- if (ret || result) + if (ret || *result) return NULL_QCOMTEE_OBJECT;
return u[1].o; diff --git a/drivers/tee/qcomtee/qcomtee.h b/drivers/tee/qcomtee/qcomtee.h index f39bf63fd1c2..66d305a46c0a 100644 --- a/drivers/tee/qcomtee/qcomtee.h +++ b/drivers/tee/qcomtee/qcomtee.h @@ -17,6 +17,8 @@ #define QCOMTEE_OBJREF_FLAG_USER BIT(1) #define QCOMTEE_OBJREF_FLAG_MEM BIT(2)
+#define QTEE_UUID_NS_NAME_SIZE 128 + /** * struct qcomtee - Main service struct. * @teedev: client device. @@ -39,6 +41,16 @@ struct qcomtee { u32 qtee_version; };
+/** + * struct qtee_service - A secure service exposed by QTEE identified by a 32-bit UID. + * @name: Name of the QTEE service. + * @uid: 32-bit UID used by QTEE to identify the service. + */ +struct qtee_service { + const char *name; + const u32 uid; +}; + void qcomtee_fetch_async_reqs(struct qcomtee_object_invoke_ctx *oic); struct qcomtee_object *qcomtee_idx_erase(struct qcomtee_object_invoke_ctx *oic, u32 idx); diff --git a/drivers/tee/qcomtee/qcomtee_msg.h b/drivers/tee/qcomtee/qcomtee_msg.h index 878f70178a5b..ecaf8db67d45 100644 --- a/drivers/tee/qcomtee/qcomtee_msg.h +++ b/drivers/tee/qcomtee/qcomtee_msg.h @@ -105,6 +105,7 @@ union qcomtee_msg_arg { #define QTEE_VERSION_GET_MINOR(x) (((x) >> 12) & 0xffU) #define QTEE_VERSION_GET_PATCH(x) ((x) >> 0 & 0xfffU)
+#define QCOMTEE_UEFI_SEC_UID 413 /* Response types as returned from qcomtee_object_invoke_ctx_invoke(). */
/* The message contains a callback request. */ diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 7bd6e23b038c..f4cb9b8fcbd4 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -316,6 +316,7 @@ qcomtee_object_get_client_env(struct qcomtee_object_invoke_ctx *oic);
struct qcomtee_object * qcomtee_object_get_service(struct qcomtee_object_invoke_ctx *oic, - struct qcomtee_object *client_env, u32 uid); + struct qcomtee_object *client_env, u32 uid, + int *result);
#endif /* QCOMTEE_OBJECT_H */
On Wed, Jul 22, 2026 at 12:29:16PM +0530, Harshal Dev wrote:
QTEE exposes certain secure services implemented either within the QTEE kernel or via pre-loaded Trusted Applications (TAs). Such always-available services can be readily accessed by TEE client drivers via QTEE's object-IPC protocol if the service is registered as a device on the TEE bus.
One such service is the EFI-variables service, implemented by the uefisecapp TA which enables kernel clients to access EFI variables at runtime.
Maintain a static list of such always-available secure services and add support for the QCOMTEE driver to register these services as devices on the TEE bus during probe.
Is it always available on all platforms supporting QTEE?
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
drivers/tee/qcomtee/call.c | 160 ++++++++++++++++++++++++++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 +++ drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 3 +- 5 files changed, 177 insertions(+), 8 deletions(-)
Hi Dmitry,
On 22-07-2026 01:59 pm, Dmitry Baryshkov wrote:
On Wed, Jul 22, 2026 at 12:29:16PM +0530, Harshal Dev wrote:
QTEE exposes certain secure services implemented either within the QTEE kernel or via pre-loaded Trusted Applications (TAs). Such always-available services can be readily accessed by TEE client drivers via QTEE's object-IPC protocol if the service is registered as a device on the TEE bus.
One such service is the EFI-variables service, implemented by the uefisecapp TA which enables kernel clients to access EFI variables at runtime.
Maintain a static list of such always-available secure services and add support for the QCOMTEE driver to register these services as devices on the TEE bus during probe.
Is it always available on all platforms supporting QTEE?
The uefisecapp service is very old. I know that it has existed since the oldest SM8x50 chipset. Every upstream supported target currently has support for it, since they all have UEFI somewhere in the boot chain to load the uefisecapp TA from the storage partition.
But as we expand this list, it's possible that certain services might not be available on older QTEE versions, in that case the service will never be registered on the TEE bus and so the TEE client driver will not probe.
Regards, Harshal
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
drivers/tee/qcomtee/call.c | 160 ++++++++++++++++++++++++++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 +++ drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 3 +- 5 files changed, 177 insertions(+), 8 deletions(-)
Hi Harshal,
On 7/22/2026 4:59 PM, Harshal Dev wrote:
QTEE exposes certain secure services implemented either within the QTEE kernel or via pre-loaded Trusted Applications (TAs). Such always-available services can be readily accessed by TEE client drivers via QTEE's object-IPC protocol if the service is registered as a device on the TEE bus.
One such service is the EFI-variables service, implemented by the uefisecapp TA which enables kernel clients to access EFI variables at runtime.
Maintain a static list of such always-available secure services and add support for the QCOMTEE driver to register these services as devices on the TEE bus during probe.
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
drivers/tee/qcomtee/call.c | 160 ++++++++++++++++++++++++++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 +++ drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 3 +- 5 files changed, 177 insertions(+), 8 deletions(-)
diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index c1bba5fbfa3e..e909955e6b21 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -662,7 +662,7 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, { struct qcomtee_object *client_env, *service; struct qcomtee_arg u[3] = { 0 };
- int result;
- int result, error = 0;
struct qcomtee_object_invoke_ctx *oic __free(kfree) = qcomtee_object_invoke_ctx_alloc(ctx, true); @@ -675,9 +675,13 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, /* Get ''FeatureVersions Service'' object. */ service = qcomtee_object_get_service(oic, client_env,
QCOMTEE_FEATURE_VER_UID);- if (service == NULL_QCOMTEE_OBJECT)
QCOMTEE_FEATURE_VER_UID,&error);- if (service == NULL_QCOMTEE_OBJECT) {
if (error)pr_err("Failed to get service! error: %d\n", error);- }
no need to check for !error (why new variable reuse result), just print "FeatureVersions Service unavailable (%d)", result The message "Failed to get service! error: %d\n" is not helpful.
/* IB: Feature to query. */ u[0].b.addr = &id; @@ -697,6 +701,153 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, qcomtee_object_put(client_env); } +/**
- is_qcomtee_service_available() - Check if the QTEE service identified by the UID
- is available
- @ctx: TEE context.
- @uid: 32-bit UID of the service.
- Returns true if the service exists and is available.
- Returns false if a service is not exposed by QTEE.
- */
+static bool is_qcomtee_service_available(struct tee_context *ctx, u32 uid) +{
- struct qcomtee_object *client_env;
- struct qcomtee_object *service;
- int error = 0;
- bool ret = false;
- struct qcomtee_object_invoke_ctx *oic __free(kfree) =
qcomtee_object_invoke_ctx_alloc(ctx, true);- if (!oic)
return ret;- client_env = qcomtee_object_get_client_env(oic);
- if (client_env == NULL_QCOMTEE_OBJECT)
return ret;- /* Get service object corresponding to the uid. */
- service = qcomtee_object_get_service(oic, client_env, uid, &error);
- if (service != NULL_QCOMTEE_OBJECT) {
qcomtee_object_put(service);ret = true;- }
- /* When we fail to get the service, QTEE provides the reason. */
- if (error)
pr_err("Failed to get service! error: %d\n", error);
This is not a useful message. We need to know which static service is missing: e.g. print "%s is unavailable (%d)", qcom.tz.uefisecapp, error. Also it is possible to re-org to avoid qcomtee_object_invoke_ctx_alloc() and qcomtee_object_get_client_env() on each iteration? oic is reusable.
- qcomtee_object_put(client_env);
- return ret;
+}
+/*
- QTEE Service UUID name space identifier
- A random UUID that is allocated as a name space identifier for forming UUID's
- representing secure services exposed by QTEE.
- */
+static const uuid_t qtee_service_uuid_ns = UUID_INIT(0xe1b48857, 0x6154, 0x49f9,
0x93, 0x4e, 0xa2, 0xf2,0x0a, 0xba, 0x98, 0x42);+static const struct qtee_service qtee_services[] = {
- { "qcom.tz.uefisecapp",
QCOMTEE_UEFI_SEC_UID }+};
+static void qtee_release_service(struct device *dev) +{
- struct tee_client_device *qtee_service = to_tee_client_device(dev);
- kfree(qtee_service);
+}
+/**
- qtee_enumerate_service() - Enumerate a given QTEE service and register
- it on the TEE bus as a TEE client device
- @ctx: TEE context.
- @service_uuid: UUID of the service to be registered on the TEE bus.
- @uid: 32-bit UID used by QTEE to identify the service.
- Returns 0 on success and < 0 on failure.
- */
+static int qtee_enumerate_service(struct tee_context *ctx, const char *service_name,
const u32 uid)+{
- struct tee_client_device *qtee_service;
- uuid_t service_uuid;
- int rc;
- if (!is_qcomtee_service_available(ctx, uid))
return -ENXIO;
-EOPNOTSUPP?
- tee_generate_uuid_v5(&service_uuid, &qtee_service_uuid_ns, service_name,
strlen(service_name));- qtee_service = kzalloc_obj(*qtee_service);
- if (!qtee_service)
return -ENOMEM;- qtee_service->dev.bus = &tee_bus_type;
- qtee_service->dev.release = qtee_release_service;
- if (dev_set_name(&qtee_service->dev, "qtee-svc-%pUb", &service_uuid)) {
kfree(qtee_service);return -ENOMEM;- }
- uuid_copy(&qtee_service->id.uuid, &service_uuid);
- rc = device_register(&qtee_service->dev);
- if (rc) {
pr_err("QTEE service registration failed, err: %d\n", rc);put_device(&qtee_service->dev);kfree(qtee_service);
It is double free!? is not put_device enough?
return rc;- }
- return 0;
+}
+/**
- qtee_enumerate_services() - Enumerate all the secure services exposed by QTEE
- from the static 'qtee_services' list and register them on the TEE bus as
- TEE client devices.
- Not all versions of QTEE support a given service. Hence, we try to
- enumerate as many services from the 'qtee_services' list as possible.
- Not being able to enumerate a service shouldn't cause the driver probe
- to fail since none of the services in the list are mandatory for
- establishing communication with QTEE.
- @ctx: TEE context.
- */
+static void qtee_enumerate_services(struct tee_context *ctx) +{
- int rc;
- u32 idx;
- for (idx = 0; idx < ARRAY_SIZE(qtee_services); idx++) {
rc = qtee_enumerate_service(ctx, qtee_services[idx].name,qtee_services[idx].uid);if (rc == -ENXIO)pr_err("QTEE does not implement service %d.\n",qtee_services[idx].uid);
If you print in is_qcomtee_service_available(), why here again?
- Amir
- }
+}
+static int qtee_unregister_service(struct device *dev, void *data) +{
- if (!strncmp(dev_name(dev), "qtee-svc", strlen("qtee-svc")))
device_unregister(dev);- return 0;
+}
+static void qtee_unregister_services(void) +{
- bus_for_each_dev(&tee_bus_type, NULL, NULL,
qtee_unregister_service);+}
static const struct tee_driver_ops qcomtee_ops = { .get_version = qcomtee_get_version, .open = qcomtee_open, @@ -778,6 +929,8 @@ static int qcomtee_probe(struct platform_device *pdev) QTEE_VERSION_GET_MINOR(qcomtee->qtee_version), QTEE_VERSION_GET_PATCH(qcomtee->qtee_version));
- qtee_enumerate_services(qcomtee->ctx);
- return 0;
err_dest_wq: @@ -807,6 +960,7 @@ static void qcomtee_remove(struct platform_device *pdev) { struct qcomtee *qcomtee = platform_get_drvdata(pdev);
- qtee_unregister_services(); teedev_close_context(qcomtee->ctx); /* Wait for RELEASE operations to be processed for QTEE objects. */ tee_device_unregister(qcomtee->teedev);
diff --git a/drivers/tee/qcomtee/core.c b/drivers/tee/qcomtee/core.c index b1cb50e434f0..4e39e867c3e9 100644 --- a/drivers/tee/qcomtee/core.c +++ b/drivers/tee/qcomtee/core.c @@ -896,19 +896,20 @@ qcomtee_object_get_client_env(struct qcomtee_object_invoke_ctx *oic) struct qcomtee_object * qcomtee_object_get_service(struct qcomtee_object_invoke_ctx *oic,
struct qcomtee_object *client_env, u32 uid)
struct qcomtee_object *client_env, u32 uid,int *result){ struct qcomtee_arg u[3] = { 0 };
- int ret, result;
- int ret;
u[0].b.addr = &uid; u[0].b.size = sizeof(uid); u[0].type = QCOMTEE_ARG_TYPE_IB; u[1].type = QCOMTEE_ARG_TYPE_OO; ret = qcomtee_object_do_invoke(oic, client_env, QCOMTEE_CLIENT_ENV_OPEN,
u, &result);
u, result);
- if (ret || result)
- if (ret || *result) return NULL_QCOMTEE_OBJECT;
return u[1].o; diff --git a/drivers/tee/qcomtee/qcomtee.h b/drivers/tee/qcomtee/qcomtee.h index f39bf63fd1c2..66d305a46c0a 100644 --- a/drivers/tee/qcomtee/qcomtee.h +++ b/drivers/tee/qcomtee/qcomtee.h @@ -17,6 +17,8 @@ #define QCOMTEE_OBJREF_FLAG_USER BIT(1) #define QCOMTEE_OBJREF_FLAG_MEM BIT(2) +#define QTEE_UUID_NS_NAME_SIZE 128
/**
- struct qcomtee - Main service struct.
- @teedev: client device.
@@ -39,6 +41,16 @@ struct qcomtee { u32 qtee_version; }; +/**
- struct qtee_service - A secure service exposed by QTEE identified by a 32-bit UID.
- @name: Name of the QTEE service.
- @uid: 32-bit UID used by QTEE to identify the service.
- */
+struct qtee_service {
- const char *name;
- const u32 uid;
+};
void qcomtee_fetch_async_reqs(struct qcomtee_object_invoke_ctx *oic); struct qcomtee_object *qcomtee_idx_erase(struct qcomtee_object_invoke_ctx *oic, u32 idx); diff --git a/drivers/tee/qcomtee/qcomtee_msg.h b/drivers/tee/qcomtee/qcomtee_msg.h index 878f70178a5b..ecaf8db67d45 100644 --- a/drivers/tee/qcomtee/qcomtee_msg.h +++ b/drivers/tee/qcomtee/qcomtee_msg.h @@ -105,6 +105,7 @@ union qcomtee_msg_arg { #define QTEE_VERSION_GET_MINOR(x) (((x) >> 12) & 0xffU) #define QTEE_VERSION_GET_PATCH(x) ((x) >> 0 & 0xfffU) +#define QCOMTEE_UEFI_SEC_UID 413 /* Response types as returned from qcomtee_object_invoke_ctx_invoke(). */ /* The message contains a callback request. */ diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 7bd6e23b038c..f4cb9b8fcbd4 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -316,6 +316,7 @@ qcomtee_object_get_client_env(struct qcomtee_object_invoke_ctx *oic); struct qcomtee_object * qcomtee_object_get_service(struct qcomtee_object_invoke_ctx *oic,
struct qcomtee_object *client_env, u32 uid);
struct qcomtee_object *client_env, u32 uid,int *result);#endif /* QCOMTEE_OBJECT_H */
Hi Amir,
On 29-07-2026 12:35 pm, Amirreza Zarrabi wrote:
Hi Harshal,
On 7/22/2026 4:59 PM, Harshal Dev wrote:
QTEE exposes certain secure services implemented either within the QTEE kernel or via pre-loaded Trusted Applications (TAs). Such always-available services can be readily accessed by TEE client drivers via QTEE's object-IPC protocol if the service is registered as a device on the TEE bus.
One such service is the EFI-variables service, implemented by the uefisecapp TA which enables kernel clients to access EFI variables at runtime.
Maintain a static list of such always-available secure services and add support for the QCOMTEE driver to register these services as devices on the TEE bus during probe.
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
drivers/tee/qcomtee/call.c | 160 ++++++++++++++++++++++++++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 +++ drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 3 +- 5 files changed, 177 insertions(+), 8 deletions(-)
diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index c1bba5fbfa3e..e909955e6b21 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -662,7 +662,7 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, { struct qcomtee_object *client_env, *service; struct qcomtee_arg u[3] = { 0 };
- int result;
- int result, error = 0;
struct qcomtee_object_invoke_ctx *oic __free(kfree) = qcomtee_object_invoke_ctx_alloc(ctx, true); @@ -675,9 +675,13 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, /* Get ''FeatureVersions Service'' object. */ service = qcomtee_object_get_service(oic, client_env,
QCOMTEE_FEATURE_VER_UID);- if (service == NULL_QCOMTEE_OBJECT)
QCOMTEE_FEATURE_VER_UID,&error);- if (service == NULL_QCOMTEE_OBJECT) {
if (error)pr_err("Failed to get service! error: %d\n", error);- }
no need to check for !error (why new variable reuse result),
Ack. will use 'result' everywhere where I am calling this. Makes sense.
just print "FeatureVersions Service unavailable (%d)", result The message "Failed to get service! error: %d\n" is not helpful.
Ack.
/* IB: Feature to query. */ u[0].b.addr = &id; @@ -697,6 +701,153 @@ static void qcomtee_get_qtee_feature_list(struct tee_context *ctx, u32 id, qcomtee_object_put(client_env); } +/**
- is_qcomtee_service_available() - Check if the QTEE service identified by the UID
- is available
- @ctx: TEE context.
- @uid: 32-bit UID of the service.
- Returns true if the service exists and is available.
- Returns false if a service is not exposed by QTEE.
- */
+static bool is_qcomtee_service_available(struct tee_context *ctx, u32 uid) +{
- struct qcomtee_object *client_env;
- struct qcomtee_object *service;
- int error = 0;
- bool ret = false;
- struct qcomtee_object_invoke_ctx *oic __free(kfree) =
qcomtee_object_invoke_ctx_alloc(ctx, true);- if (!oic)
return ret;- client_env = qcomtee_object_get_client_env(oic);
- if (client_env == NULL_QCOMTEE_OBJECT)
return ret;- /* Get service object corresponding to the uid. */
- service = qcomtee_object_get_service(oic, client_env, uid, &error);
- if (service != NULL_QCOMTEE_OBJECT) {
qcomtee_object_put(service);ret = true;- }
- /* When we fail to get the service, QTEE provides the reason. */
- if (error)
pr_err("Failed to get service! error: %d\n", error);This is not a useful message. We need to know which static service is missing: e.g. print "%s is unavailable (%d)", qcom.tz.uefisecapp, error.
Ack.
Also it is possible to re-org to avoid qcomtee_object_invoke_ctx_alloc() and qcomtee_object_get_client_env() on each iteration? oic is reusable.
Agreed, since this is called in a loop, it results in unnecessary re-allocation on every iteration and call to QTEE for getting client_env(). Ack.
- qcomtee_object_put(client_env);
- return ret;
+}
+/*
- QTEE Service UUID name space identifier
- A random UUID that is allocated as a name space identifier for forming UUID's
- representing secure services exposed by QTEE.
- */
+static const uuid_t qtee_service_uuid_ns = UUID_INIT(0xe1b48857, 0x6154, 0x49f9,
0x93, 0x4e, 0xa2, 0xf2,0x0a, 0xba, 0x98, 0x42);+static const struct qtee_service qtee_services[] = {
- { "qcom.tz.uefisecapp",
QCOMTEE_UEFI_SEC_UID }+};
+static void qtee_release_service(struct device *dev) +{
- struct tee_client_device *qtee_service = to_tee_client_device(dev);
- kfree(qtee_service);
+}
+/**
- qtee_enumerate_service() - Enumerate a given QTEE service and register
- it on the TEE bus as a TEE client device
- @ctx: TEE context.
- @service_uuid: UUID of the service to be registered on the TEE bus.
- @uid: 32-bit UID used by QTEE to identify the service.
- Returns 0 on success and < 0 on failure.
- */
+static int qtee_enumerate_service(struct tee_context *ctx, const char *service_name,
const u32 uid)+{
- struct tee_client_device *qtee_service;
- uuid_t service_uuid;
- int rc;
- if (!is_qcomtee_service_available(ctx, uid))
return -ENXIO;-EOPNOTSUPP?
Ack.
- tee_generate_uuid_v5(&service_uuid, &qtee_service_uuid_ns, service_name,
strlen(service_name));- qtee_service = kzalloc_obj(*qtee_service);
- if (!qtee_service)
return -ENOMEM;- qtee_service->dev.bus = &tee_bus_type;
- qtee_service->dev.release = qtee_release_service;
- if (dev_set_name(&qtee_service->dev, "qtee-svc-%pUb", &service_uuid)) {
kfree(qtee_service);return -ENOMEM;- }
- uuid_copy(&qtee_service->id.uuid, &service_uuid);
- rc = device_register(&qtee_service->dev);
- if (rc) {
pr_err("QTEE service registration failed, err: %d\n", rc);put_device(&qtee_service->dev);kfree(qtee_service);It is double free!? is not put_device enough?
Thank you for catching this, I did not realize that put_device frees the entire struct.
Ack.
return rc;- }
- return 0;
+}
+/**
- qtee_enumerate_services() - Enumerate all the secure services exposed by QTEE
- from the static 'qtee_services' list and register them on the TEE bus as
- TEE client devices.
- Not all versions of QTEE support a given service. Hence, we try to
- enumerate as many services from the 'qtee_services' list as possible.
- Not being able to enumerate a service shouldn't cause the driver probe
- to fail since none of the services in the list are mandatory for
- establishing communication with QTEE.
- @ctx: TEE context.
- */
+static void qtee_enumerate_services(struct tee_context *ctx) +{
- int rc;
- u32 idx;
- for (idx = 0; idx < ARRAY_SIZE(qtee_services); idx++) {
rc = qtee_enumerate_service(ctx, qtee_services[idx].name,qtee_services[idx].uid);if (rc == -ENXIO)pr_err("QTEE does not implement service %d.\n",qtee_services[idx].uid);If you print in is_qcomtee_service_available(), why here again?
Ack, will remove from here.
Regards, Harshal
- Amir
- }
+}
+static int qtee_unregister_service(struct device *dev, void *data) +{
- if (!strncmp(dev_name(dev), "qtee-svc", strlen("qtee-svc")))
device_unregister(dev);- return 0;
+}
+static void qtee_unregister_services(void) +{
- bus_for_each_dev(&tee_bus_type, NULL, NULL,
qtee_unregister_service);+}
static const struct tee_driver_ops qcomtee_ops = { .get_version = qcomtee_get_version, .open = qcomtee_open, @@ -778,6 +929,8 @@ static int qcomtee_probe(struct platform_device *pdev) QTEE_VERSION_GET_MINOR(qcomtee->qtee_version), QTEE_VERSION_GET_PATCH(qcomtee->qtee_version));
- qtee_enumerate_services(qcomtee->ctx);
- return 0;
err_dest_wq: @@ -807,6 +960,7 @@ static void qcomtee_remove(struct platform_device *pdev) { struct qcomtee *qcomtee = platform_get_drvdata(pdev);
- qtee_unregister_services(); teedev_close_context(qcomtee->ctx); /* Wait for RELEASE operations to be processed for QTEE objects. */ tee_device_unregister(qcomtee->teedev);
diff --git a/drivers/tee/qcomtee/core.c b/drivers/tee/qcomtee/core.c index b1cb50e434f0..4e39e867c3e9 100644 --- a/drivers/tee/qcomtee/core.c +++ b/drivers/tee/qcomtee/core.c @@ -896,19 +896,20 @@ qcomtee_object_get_client_env(struct qcomtee_object_invoke_ctx *oic) struct qcomtee_object * qcomtee_object_get_service(struct qcomtee_object_invoke_ctx *oic,
struct qcomtee_object *client_env, u32 uid)
struct qcomtee_object *client_env, u32 uid,int *result){ struct qcomtee_arg u[3] = { 0 };
- int ret, result;
- int ret;
u[0].b.addr = &uid; u[0].b.size = sizeof(uid); u[0].type = QCOMTEE_ARG_TYPE_IB; u[1].type = QCOMTEE_ARG_TYPE_OO; ret = qcomtee_object_do_invoke(oic, client_env, QCOMTEE_CLIENT_ENV_OPEN,
u, &result);
u, result);
- if (ret || result)
- if (ret || *result) return NULL_QCOMTEE_OBJECT;
return u[1].o; diff --git a/drivers/tee/qcomtee/qcomtee.h b/drivers/tee/qcomtee/qcomtee.h index f39bf63fd1c2..66d305a46c0a 100644 --- a/drivers/tee/qcomtee/qcomtee.h +++ b/drivers/tee/qcomtee/qcomtee.h @@ -17,6 +17,8 @@ #define QCOMTEE_OBJREF_FLAG_USER BIT(1) #define QCOMTEE_OBJREF_FLAG_MEM BIT(2) +#define QTEE_UUID_NS_NAME_SIZE 128
/**
- struct qcomtee - Main service struct.
- @teedev: client device.
@@ -39,6 +41,16 @@ struct qcomtee { u32 qtee_version; }; +/**
- struct qtee_service - A secure service exposed by QTEE identified by a 32-bit UID.
- @name: Name of the QTEE service.
- @uid: 32-bit UID used by QTEE to identify the service.
- */
+struct qtee_service {
- const char *name;
- const u32 uid;
+};
void qcomtee_fetch_async_reqs(struct qcomtee_object_invoke_ctx *oic); struct qcomtee_object *qcomtee_idx_erase(struct qcomtee_object_invoke_ctx *oic, u32 idx); diff --git a/drivers/tee/qcomtee/qcomtee_msg.h b/drivers/tee/qcomtee/qcomtee_msg.h index 878f70178a5b..ecaf8db67d45 100644 --- a/drivers/tee/qcomtee/qcomtee_msg.h +++ b/drivers/tee/qcomtee/qcomtee_msg.h @@ -105,6 +105,7 @@ union qcomtee_msg_arg { #define QTEE_VERSION_GET_MINOR(x) (((x) >> 12) & 0xffU) #define QTEE_VERSION_GET_PATCH(x) ((x) >> 0 & 0xfffU) +#define QCOMTEE_UEFI_SEC_UID 413 /* Response types as returned from qcomtee_object_invoke_ctx_invoke(). */ /* The message contains a callback request. */ diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 7bd6e23b038c..f4cb9b8fcbd4 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -316,6 +316,7 @@ qcomtee_object_get_client_env(struct qcomtee_object_invoke_ctx *oic); struct qcomtee_object * qcomtee_object_get_service(struct qcomtee_object_invoke_ctx *oic,
struct qcomtee_object *client_env, u32 uid);
struct qcomtee_object *client_env, u32 uid,int *result);#endif /* QCOMTEE_OBJECT_H */
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 + help + On Qualcomm SoC based platforms without emulated RPMB support, + 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" + +static struct qcomtee_uefisec_app uefisec_app; + +static int qcuefi_get_variable(struct tee_param_ubuf in_variable, efi_guid_t *guid, + struct tee_param_ubuf in_attributes, + struct tee_param_ubuf *data, + u32 *out_attributes, u32 *out_errno) +{ + int ret; + struct tee_ioctl_object_invoke_arg inv_arg; + u64 obj_id = uefisec_app.uefisec_svc_obj.id; + u32 nparams = 5; + struct tee_param param[nparams]; + + struct { + efi_guid_t guid; + u32 in_data_size; + } in_cong = { 0 }; + + struct { + u32 out_data_size; + u32 attributes; + u32 errno; + } out_cong = { 0 }; + + in_cong.guid = *guid; + in_cong.in_data_size = data->size; + + memset(&inv_arg, 0, sizeof(inv_arg)); + memset(¶m, 0, sizeof(param)); + + SET_INVOKE_ARG(inv_arg, obj_id, QCOMTEE_UEFI_SEC_OP_GET_VAR, nparams); + SET_TEE_PARAM_UBUF(param[0], UBUF_INPUT, TEE_PARAM_UBUF(in_cong)); + SET_TEE_PARAM_UBUF(param[1], UBUF_INPUT, in_variable); + SET_TEE_PARAM_UBUF(param[2], UBUF_INPUT, in_attributes); + SET_TEE_PARAM_UBUF(param[3], UBUF_OUTPUT, TEE_PARAM_UBUF(out_cong)); + SET_TEE_PARAM_UBUF(param[4], UBUF_OUTPUT, *data); + + ret = tee_client_object_invoke_func(uefisec_app.ctx, &inv_arg, param); + if (ret < 0 || inv_arg.ret != 0) { + dev_err(uefisec_app.dev, "QCOMTEE_UEFI_SEC_OP_GET_VAR invoke ret: %d, err: 0x%x\n", + ret, inv_arg.ret); + return ret ?: inv_arg.ret; + } + + data->size = out_cong.out_data_size; + *out_attributes = out_cong.attributes; + *out_errno = out_cong.errno; + + return ret; +} + +static efi_status_t qcomtee_uefi_get_variable(efi_char16_t *name, efi_guid_t *guid, + u32 *attr, unsigned long *data_size, + void *data) +{ + int ret; + u32 in_attr, out_attributes, out_errno; + struct tee_param_ubuf in_data, in_var, in_attributes; + + if (!name || !guid) + return EFI_INVALID_PARAMETER; + + /* 'attr' can be NULL, however an input attribute is always expected + * by UefiSecApp TA + */ + in_attr = 0; + if (attr) + in_attr = *attr; + + in_data = (struct tee_param_ubuf){ .addr = data, *data_size }; + in_var = (struct tee_param_ubuf){ .addr = name, + (ucs2_strlen(name) + 1) * sizeof(*name) }; + in_attributes = (struct tee_param_ubuf){ .addr = &in_attr, sizeof(u32) }; + + /* On SUCCESS, 'data' member of 'in_data' has already been updated. */ + ret = qcuefi_get_variable(in_var, guid, in_attributes, &in_data, + &out_attributes, &out_errno); + + if (ret) + return EFI_DEVICE_ERROR; + + if (!out_errno || out_errno == QCOMTEE_UEFI_SEC_ERROR_SIZE_OUT) { + /* If 'attr' is NULL 'out_attributes' is not updated. */ + if (attr) + *attr = out_attributes; + + *data_size = in_data.size; + } + + return uefisecapp_err_to_efi_status(out_errno); +} + +static int qcuefi_set_variable(struct tee_param_ubuf in_variable, efi_guid_t *guid, + u32 attributes, struct tee_param_ubuf data, + u32 *out_errno) +{ + int ret; + struct tee_ioctl_object_invoke_arg inv_arg; + u64 obj_id = uefisec_app.uefisec_svc_obj.id; + u32 nparams = 4; + struct tee_param param[nparams]; + + struct { + efi_guid_t guid; + u32 attributes; + u32 in_data_size; + } in_cong = { 0 }; + + in_cong.guid = *guid; + in_cong.attributes = attributes; + in_cong.in_data_size = data.size; + + memset(&inv_arg, 0, sizeof(inv_arg)); + memset(¶m, 0, sizeof(param)); + + SET_INVOKE_ARG(inv_arg, obj_id, QCOMTEE_UEFI_SEC_OP_SET_VAR, nparams); + SET_TEE_PARAM_UBUF(param[0], UBUF_INPUT, TEE_PARAM_UBUF(in_cong)); + SET_TEE_PARAM_UBUF(param[1], UBUF_INPUT, in_variable); + SET_TEE_PARAM_UBUF(param[2], UBUF_INPUT, data); + SET_TEE_PARAM_UBUF(param[3], UBUF_OUTPUT, TEE_PARAM_UBUF(*out_errno)); + + ret = tee_client_object_invoke_func(uefisec_app.ctx, &inv_arg, param); + if (ret < 0 || inv_arg.ret != 0) { + dev_err(uefisec_app.dev, "QCOMTEE_UEFI_SEC_OP_SET_VAR invoke ret: %d, err: 0x%x\n", + ret, inv_arg.ret); + return ret ?: inv_arg.ret; + } + + return ret; +} + +static efi_status_t qcomtee_uefi_set_variable(efi_char16_t *name, efi_guid_t *guid, + u32 attr, unsigned long data_size, + void *data) +{ + int ret; + u32 out_errno; + struct tee_param_ubuf in_data, in_var; + + if (!name || !guid) + return EFI_INVALID_PARAMETER; + + in_data = (struct tee_param_ubuf){ .addr = data, data_size }; + in_var = (struct tee_param_ubuf){ .addr = name, + (ucs2_strlen(name) + 1) * sizeof(*name) }; + + ret = qcuefi_set_variable(in_var, guid, attr, in_data, &out_errno); + if (ret) + return EFI_DEVICE_ERROR; + + return uefisecapp_err_to_efi_status(out_errno); +} + +static int qcuefi_get_next_variable(struct tee_param_ubuf in_variable, efi_guid_t *guid, + struct tee_param_ubuf *out_variable, + efi_guid_t *out_vendor_guid, u32 *out_errno) +{ + int ret; + struct tee_ioctl_object_invoke_arg inv_arg; + u64 obj_id = uefisec_app.uefisec_svc_obj.id; + u32 nparams = 4; + struct tee_param param[nparams]; + + struct { + efi_guid_t guid; + u32 in_data_size; + } in_cong = { 0 }; + + struct { + efi_guid_t guid; + u32 out_data_size; + u32 errno; + } out_cong = { 0 }; + + /* Pass size of available buffer */ + in_cong.in_data_size = out_variable->size; + in_cong.guid = *guid; + + memset(&inv_arg, 0, sizeof(inv_arg)); + memset(¶m, 0, sizeof(param)); + + SET_INVOKE_ARG(inv_arg, obj_id, QCOMTEE_UEFI_SEC_OP_GET_NEXT_VAR_NAME, nparams); + SET_TEE_PARAM_UBUF(param[0], UBUF_INPUT, TEE_PARAM_UBUF(in_cong)); + SET_TEE_PARAM_UBUF(param[1], UBUF_INPUT, in_variable); + SET_TEE_PARAM_UBUF(param[2], UBUF_OUTPUT, TEE_PARAM_UBUF(out_cong)); + SET_TEE_PARAM_UBUF(param[3], UBUF_OUTPUT, *out_variable); + + ret = tee_client_object_invoke_func(uefisec_app.ctx, &inv_arg, param); + if (ret < 0 || inv_arg.ret != 0) { + dev_err(uefisec_app.dev, "QCOMTEE_UEFI_SEC_OP_GET_NEXT_VAR_NAME invoke ret: %d, err: 0x%x\n", + ret, inv_arg.ret); + return ret ?: inv_arg.ret; + } + + /* UefiSecApp TA does not touch 'out_variable.size'. Update it here. + * On SUCCESS (!out_errno), 'out_data_size' is length of name in 'out_variable.addr'. + * On failure (out_errno == QCOMTEE_UEFI_SEC_ERROR_SIZE_OUT), 'out_data_size' is + * actual name length. + * Otherwise, it's undefined. + */ + out_variable->size = out_cong.out_data_size; + *out_vendor_guid = out_cong.guid; + *out_errno = out_cong.errno; + + return ret; +} + +static efi_status_t qcomtee_uefi_get_next_variable(unsigned long *name_size, + efi_char16_t *name, + efi_guid_t *guid) +{ + int ret; + u32 out_errno; + efi_guid_t out_guid; + struct tee_param_ubuf in_var, out_var; + + if (!name_size || !name || !guid) + return EFI_INVALID_PARAMETER; + + if (*name_size == 0) + return EFI_INVALID_PARAMETER; + + /* For 'in_var', 'name_size' is not necessarily size of 'name'; + * could be size of buffer where 'name' has been stored. TA expects a + * NULL-terminated string in 'name' and ignores the size. + * For 'out_var', 'name_size' is size of buffer pointed by 'name'. + */ + in_var = (struct tee_param_ubuf){ .addr = name, *name_size }; + out_var = (struct tee_param_ubuf){ .addr = name, *name_size }; + + ret = qcuefi_get_next_variable(in_var, guid, &out_var, &out_guid, + &out_errno); + if (ret) + return EFI_DEVICE_ERROR; + + if (!out_errno) + *guid = out_guid; + + if (!out_errno || out_errno == QCOMTEE_UEFI_SEC_ERROR_SIZE_OUT) + *name_size = out_var.size; + + /* On SUCCESS, 'name' stores the next variable name. */ + return uefisecapp_err_to_efi_status(out_errno); +} + +static int qcuefi_query_variable_info(u32 attributes, + u64 *maximum_variable_storage_size, + u64 *remaining_variable_storage_size, + u64 *maximum_variable_size, u32 *out_errno) +{ + int ret; + struct tee_ioctl_object_invoke_arg inv_arg; + u64 obj_id = uefisec_app.uefisec_svc_obj.id; + u32 nparams = 2; + struct tee_param param[nparams]; + + struct { + u64 max_var_storage_size; + u64 remaining_var_storage_size; + u64 maximum_var_size; + u32 errno; + } out_cong = { 0 }; + + memset(&inv_arg, 0, sizeof(inv_arg)); + memset(¶m, 0, sizeof(param)); + + SET_INVOKE_ARG(inv_arg, obj_id, QCOMTEE_UEFI_SEC_OP_QUERY_VAR_INFO, nparams); + SET_TEE_PARAM_UBUF(param[0], UBUF_INPUT, TEE_PARAM_UBUF(attributes)); + SET_TEE_PARAM_UBUF(param[1], UBUF_OUTPUT, TEE_PARAM_UBUF(out_cong)); + + ret = tee_client_object_invoke_func(uefisec_app.ctx, &inv_arg, param); + if (ret < 0 || inv_arg.ret != 0) { + dev_err(uefisec_app.dev, "QCOMTEE_UEFI_SEC_OP_QUERY_VAR_INFO invoke ret: %d, err: 0x%x\n", + ret, inv_arg.ret); + return ret ?: inv_arg.ret; + } + + *maximum_variable_storage_size = out_cong.max_var_storage_size; + *remaining_variable_storage_size = out_cong.remaining_var_storage_size; + *maximum_variable_size = out_cong.maximum_var_size; + *out_errno = out_cong.errno; + + return ret; +} + +static efi_status_t qcomtee_uefi_query_variable_info(u32 attr, u64 *storage_space, + u64 *remaining_space, + u64 *max_variable_size) +{ + int ret; + u32 out_errno; + u64 maximum_variable_storage_size; + u64 remaining_variable_storage_size; + u64 maximum_variable_size; + + if (!storage_space || !remaining_space || !max_variable_size) + return EFI_INVALID_PARAMETER; + + ret = qcuefi_query_variable_info(attr, + &maximum_variable_storage_size, + &remaining_variable_storage_size, + &maximum_variable_size, + &out_errno); + + if (ret) + return EFI_DEVICE_ERROR; + + if (!out_errno) { + *storage_space = maximum_variable_storage_size; + *remaining_space = remaining_variable_storage_size; + *max_variable_size = maximum_variable_size; + } + + return uefisecapp_err_to_efi_status(out_errno); +} + +/** + * qcomtee_release_object() - Release an object returned by QTEE. + * + * Each object returned by QTEE repesents a secure service exposed to the + * client. Whenever an secure service is opened, QTEE may allocate resources + * on the client's behalf. Therefore, once the client is done accessing the + * secure service, the object representing it should be explicitly released + * so that QTEE can release the associated resources as well. + * + * @ctx: TEE context. + * @object: The object to release. + */ +static void qcomtee_release_object(struct tee_context *ctx, + struct tee_param_objref object) +{ + struct tee_ioctl_object_invoke_arg inv_arg; + + memset(&inv_arg, 0, sizeof(inv_arg)); + SET_INVOKE_ARG(inv_arg, object.id, QCOMTEE_MSG_OBJECT_OP_RELEASE, 0); + tee_client_object_invoke_func(ctx, &inv_arg, NULL); +} + +/** + * qcomtee_get_uefisec_svc_obj() - Get a UEFI Secure App service object to + * begin communication with the service. + * @ctx: TEE context. + * @client_env_obj: The client environment object returned earlier by QTEE. + * @uefisec_svc_obj: The UEFI Secure App service object. + * + * Returns 0 on success. + * Returns < 0 if client environment object invocation failed. + * Returns > 0 if client environment invocation was success but UEFI Secure App + * service object could not be returned for some other reason (represented by the + * returned value) + */ +static int qcomtee_get_uefisec_svc_obj(struct tee_context *ctx, + struct tee_param_objref client_env_obj, + struct tee_param_objref *uefisec_svc_obj) +{ + int ret; + struct tee_ioctl_object_invoke_arg inv_arg; + u64 obj_id = client_env_obj.id; + u32 nparams = 2; + struct tee_param param[nparams]; + u32 uefisec_uid = QCOMTEE_UEFI_SEC_UID; + + memset(&inv_arg, 0, sizeof(inv_arg)); + memset(¶m, 0, sizeof(param)); + + SET_INVOKE_ARG(inv_arg, obj_id, QCOMTEE_OP_CLIENT_ENV_OPEN, nparams); + SET_TEE_PARAM_UBUF(param[0], UBUF_INPUT, TEE_PARAM_UBUF(uefisec_uid)); + SET_TEE_PARAM_OBJREF(param[1], OBJREF_OUTPUT, 0, 0); + + ret = tee_client_object_invoke_func(ctx, &inv_arg, param); + if (ret < 0 || inv_arg.ret != 0) { + dev_err(uefisec_app.dev, "QCOMTEE_CLIENT_ENV_OPEN invoke ret: %d, err: 0x%x\n", + ret, inv_arg.ret); + return ret ?: inv_arg.ret; + } + + *uefisec_svc_obj = param[1].u.objref; + return ret; +} + +/** + * qcomtee_get_client_env_obj() - Get a client environment object to begin + * object exchange with QTEE. + * @ctx: TEE context. + * @client_env_obj: The client environment object returned by QTEE. + * + * Returns 0 on success. + * Returns < 0 if root object invocation failed. + * Returns > 0 if root object invocation was success but client environment + * object could not be returned for some other reason (represented by the + * returned value) + */ +static int qcomtee_get_client_env_obj(struct tee_context *ctx, + struct tee_param_objref *client_env_obj) +{ + int ret; + struct tee_ioctl_object_invoke_arg inv_arg; + u32 nparams = 2; + struct tee_param param[nparams]; + + memset(&inv_arg, 0, sizeof(inv_arg)); + memset(¶m, 0, sizeof(param)); + + SET_INVOKE_ARG(inv_arg, TEE_OBJREF_NULL, + QCOMTEE_ROOT_OP_REG_WITH_CREDENTIALS, nparams); + SET_TEE_PARAM_OBJREF(param[0], OBJREF_INPUT, TEE_OBJREF_NULL, 0); + SET_TEE_PARAM_OBJREF(param[1], OBJREF_OUTPUT, 0, 0); + + ret = tee_client_object_invoke_func(ctx, &inv_arg, param); + if (ret < 0 || inv_arg.ret != 0) { + dev_err(uefisec_app.dev, "QCOMTEE_ROOT_OP_REG_WITH_CREDENTIALS invoke ret: %d, err: 0x%x\n", + ret, inv_arg.ret); + return ret ?: inv_arg.ret; + } + + *client_env_obj = param[1].u.objref; + return ret; +} + +static const struct efivar_operations qcom_efivar_ops = { + .get_variable = qcomtee_uefi_get_variable, + .set_variable = qcomtee_uefi_set_variable, + .get_next_variable = qcomtee_uefi_get_next_variable, + .query_variable_info = qcomtee_uefi_query_variable_info, +}; + +static int qcomtee_ctx_match(struct tee_ioctl_version_data *ver, + const void *data) +{ + return (ver->impl_id == TEE_IMPL_ID_QTEE); +} + +static int qcomtee_uefisecapp_probe(struct tee_client_device *tee_dev) +{ + int ret, err; + struct tee_param_objref client_env_obj; + struct tee_param_objref uefisec_svc_obj; + + uefisec_app.dev = &tee_dev->dev; + /* Open context with QCOMTEE driver */ + uefisec_app.ctx = tee_client_open_context(NULL, qcomtee_ctx_match, NULL, + NULL); + if (IS_ERR(uefisec_app.ctx)) + return -ENODEV; + + /* Obtain a reference to client_env object to begin object exchange + * with QTEE + */ + ret = qcomtee_get_client_env_obj(uefisec_app.ctx, &client_env_obj); + if (ret) { + err = -EINVAL; + goto err_get_client_env; + } + + /* Obtain a reference to the uefisec_svc object which provides access to + * the EFI var storage. + */ + ret = qcomtee_get_uefisec_svc_obj(uefisec_app.ctx, client_env_obj, + &uefisec_svc_obj); + if (ret) { + err = -EINVAL; + goto err_get_uefisec_svc; + } + uefisec_app.uefisec_svc_obj = uefisec_svc_obj; + + ret = efivars_register(&uefisec_app.efivars, &qcom_efivar_ops); + if (ret) { + err = ret; + goto err_efi_vars_reg; + } + + /* We don't need to keep a reference to this object anymore, we only + * needed it to obtain the uefisec_svc object. + */ + qcomtee_release_object(uefisec_app.ctx, client_env_obj); + return 0; + +err_efi_vars_reg: + qcomtee_release_object(uefisec_app.ctx, uefisec_svc_obj); +err_get_uefisec_svc: + qcomtee_release_object(uefisec_app.ctx, client_env_obj); +err_get_client_env: + tee_client_close_context(uefisec_app.ctx); + + return err; +} + +static void qcomtee_uefisecapp_remove(struct tee_client_device *tee_dev) +{ + efivars_unregister(&uefisec_app.efivars); + qcomtee_release_object(uefisec_app.ctx, uefisec_app.uefisec_svc_obj); + tee_client_close_context(uefisec_app.ctx); +} + +static const struct tee_client_device_id qcomtee_uefisecapp_id_table[] = { + {UEFISECAPP_UUID}, + {} +}; +MODULE_DEVICE_TABLE(tee, qcomtee_uefisecapp_id_table); + +static struct tee_client_driver qcomtee_uefisecapp_driver = { + .id_table = qcomtee_uefisecapp_id_table, + .probe = qcomtee_uefisecapp_probe, + .remove = qcomtee_uefisecapp_remove, + .driver = { + .name = "qcom-tee-uefisecapp", + }, +}; + +module_tee_client_driver(qcomtee_uefisecapp_driver); + +MODULE_AUTHOR("Qualcomm"); +MODULE_DESCRIPTION("TEE client driver for Qualcomm TEE UEFI Secure App"); +MODULE_LICENSE("GPL"); diff --git a/drivers/firmware/qcom/qcom_tee_uefisecapp.h b/drivers/firmware/qcom/qcom_tee_uefisecapp.h new file mode 100644 index 000000000000..a014c18cfed0 --- /dev/null +++ b/drivers/firmware/qcom/qcom_tee_uefisecapp.h @@ -0,0 +1,120 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries. + */ + +#ifndef QCOM_TEE_UEFISECAPP_H +#define QCOM_TEE_UEFISECAPP_H + +#define QCOMTEE_OP_CLIENT_ENV_OPEN 0 +#define QCOMTEE_ROOT_OP_REG_WITH_CREDENTIALS 5 + +/* Each service exposed by QTEE is identified by a 32-bit UID */ +#define QCOMTEE_UEFI_SEC_UID 413 + +/* Operations supported by the UEFI Sec App service */ +#define QCOMTEE_UEFI_SEC_OP_GET_VAR 0 +#define QCOMTEE_UEFI_SEC_OP_SET_VAR 1 +#define QCOMTEE_UEFI_SEC_OP_QUERY_VAR_INFO 2 +#define QCOMTEE_UEFI_SEC_OP_GET_NEXT_VAR_NAME 3 + +/* Error codes returned by the UEFI Sec App service */ +#define QCOMTEE_UEFI_SEC_SUCCESS 0 +#define QCOMTEE_UEFI_SEC_ERROR_INVALID_PARAMETER 10 +#define QCOMTEE_UEFI_SEC_ERROR_UNSUPPORTED 11 +#define QCOMTEE_UEFI_SEC_ERROR_WRITE_PROTECTED 12 +#define QCOMTEE_UEFI_SEC_ERROR_SECURITY_VIOLATION 13 +#define QCOMTEE_UEFI_SEC_ERROR_DEVICE_ERROR 14 +#define QCOMTEE_UEFI_SEC_ERROR_OUT_OF_RESOURCES 15 +#define QCOMTEE_UEFI_SEC_ERROR_VOLUME_CORRUPTED 16 +#define QCOMTEE_UEFI_SEC_ERROR_SIZE_OUT 17 +#define QCOMTEE_UEFI_SEC_ERROR_NOT_FOUND 18 +#define QCOMTEE_UEFI_SEC_ERROR_ALREADY_STARTED 19 + +/* Operations for objects are 32-bit. QCOMTEE transport uses the upper 16 bits. */ +#define QCOMTEE_MSG_OBJECT_OP_MASK GENMASK(15, 0) +#define QCOMTEE_MSG_OBJECT_OP_RELEASE (QCOMTEE_MSG_OBJECT_OP_MASK - 0) + +/** + * struct qcomtee_uefisec_app - An instance of UEFI Secure Application. + * @dev: TEE client device on the TEE bus which represents uefisecapp. + * @ctx: The context opened with the TEE subsystem by the uefisecapp client. + * @uefisec_svc_obj: A TEE object representing the uefisecapp service. + * @efivars: EFI variables registered with the EFI subsystem. + */ +struct qcomtee_uefisec_app { + struct device *dev; + struct tee_context *ctx; + struct tee_param_objref uefisec_svc_obj; + struct efivars efivars; +}; + +#define UEFISECAPP_UUID \ + UUID_INIT(0x01f95dcd, 0x2d7e, 0x58be, \ + 0xa1, 0x43, 0x81, 0x32, 0xa1, 0x72, 0xdb, 0x7d) + +/* Short-hands for these long attribute names */ +#define UBUF_INPUT TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_INPUT +#define UBUF_OUTPUT TEE_IOCTL_PARAM_ATTR_TYPE_UBUF_OUTPUT +#define OBJREF_INPUT TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_INPUT +#define OBJREF_OUTPUT TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_OUTPUT + +/* Init instance of 'struct tee_param_objref'. */ +#define SET_TEE_PARAM_OBJREF(param, attri, obj_id, obj_flag) do { \ + (param).attr = (attri); \ + (param).u.objref.id = (obj_id); \ + (param).u.objref.flags = (obj_flag); \ + } while (0) + +/* Init instance of 'struct tee_param_ubuf'. */ +#define SET_TEE_PARAM_UBUF(param, attri, ubuff) do { \ + (param).attr = (attri); \ + (param).u.ubuf = (ubuff); \ + } while (0) + +#define TEE_PARAM_UBUF(x) ((struct tee_param_ubuf){ .addr = &(x), sizeof(x) }) + +#define SET_INVOKE_ARG(arg, object_id, opp, nparam) do { \ + (arg).id = (object_id); \ + (arg).op = (opp); \ + (arg).num_params = (nparam); \ + } while (0) + +static inline efi_status_t uefisecapp_err_to_efi_status(u32 err) +{ + switch (err) { + case QCOMTEE_UEFI_SEC_SUCCESS: + return EFI_SUCCESS; + + case QCOMTEE_UEFI_SEC_ERROR_INVALID_PARAMETER: + return EFI_INVALID_PARAMETER; + + case QCOMTEE_UEFI_SEC_ERROR_UNSUPPORTED: + return EFI_UNSUPPORTED; + + case QCOMTEE_UEFI_SEC_ERROR_WRITE_PROTECTED: + return EFI_WRITE_PROTECTED; + + case QCOMTEE_UEFI_SEC_ERROR_SECURITY_VIOLATION: + return EFI_SECURITY_VIOLATION; + + case QCOMTEE_UEFI_SEC_ERROR_DEVICE_ERROR: + return EFI_DEVICE_ERROR; + + case QCOMTEE_UEFI_SEC_ERROR_OUT_OF_RESOURCES: + return EFI_OUT_OF_RESOURCES; + + case QCOMTEE_UEFI_SEC_ERROR_SIZE_OUT: + return EFI_BUFFER_TOO_SMALL; + + case QCOMTEE_UEFI_SEC_ERROR_NOT_FOUND: + return EFI_NOT_FOUND; + + /* No matching on EFI_* list. */ + case QCOMTEE_UEFI_SEC_ERROR_ALREADY_STARTED: /* EFI_ALREADY_STARTED. */ + case QCOMTEE_UEFI_SEC_ERROR_VOLUME_CORRUPTED: /* EFI_VOLUME_CORRUPTED. */ + default: + return EFI_DEVICE_ERROR; + } +} +#endif /* QCOM_TEE_UEFISECAPP_H */
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 storageand instead located on UFS/EMMC storage, non-volatile EFI variables canonly be set via a callback request from the UEFI Secure Application tothe RPMB service running in user-space (within the QTEE supplicant:github.com/qualcomm/minkipc). Unlike the QCOMTEE driver, the QSEECOMdriver used by the QSEECOM based uefisecapp does not support callbackrequests. And so on these platforms, the TEE based uefisecapp clientdriver must be used to ensure persistence of non-volatile EFI variablesvia writes through the RPMB service hosted in the QTEE supplicant.This module provides a TEE client driver for uefisecapp, installing efivaroperations to allow the kernel and user-space access to EFI variables.Select m here to provide access to EFI variables on the aforementionedplatforms if your Linux distribution has QTEE supplicant installed andrunning.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()?
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@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.
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 storageand instead located on UFS/EMMC storage, non-volatile EFI variables canonly be set via a callback request from the UEFI Secure Application tothe RPMB service running in user-space (within the QTEE supplicant:github.com/qualcomm/minkipc). Unlike the QCOMTEE driver, the QSEECOMdriver used by the QSEECOM based uefisecapp does not support callbackrequests. And so on these platforms, the TEE based uefisecapp clientdriver must be used to ensure persistence of non-volatile EFI variablesvia writes through the RPMB service hosted in the QTEE supplicant.This module provides a TEE client driver for uefisecapp, installing efivaroperations to allow the kernel and user-space access to EFI variables.Select m here to provide access to EFI variables on the aforementionedplatforms if your Linux distribution has QTEE supplicant installed andrunning.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()?
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 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.
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 storageand instead located on UFS/EMMC storage, non-volatile EFI variables canonly be set via a callback request from the UEFI Secure Application tothe RPMB service running in user-space (within the QTEE supplicant:github.com/qualcomm/minkipc). Unlike the QCOMTEE driver, the QSEECOMdriver used by the QSEECOM based uefisecapp does not support callbackrequests. And so on these platforms, the TEE based uefisecapp clientdriver must be used to ensure persistence of non-volatile EFI variablesvia writes through the RPMB service hosted in the QTEE supplicant.This module provides a TEE client driver for uefisecapp, installing efivaroperations to allow the kernel and user-space access to EFI variables.Select m here to provide access to EFI variables on the aforementionedplatforms if your Linux distribution has QTEE supplicant installed andrunning.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/t... https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/firmware/qcom/qcom_...
Apologies for missing out on these two comments in the previous reply.
Regards, Harshal
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...
For Qualcomm platforms without emulated RPMB support, specifically
What is emulated RPMB support? Why is it mentioned here? Which platforms use emulated RPMB?
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?
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.
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?
On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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?
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.
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?
This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example.
Merge Strategy:
This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch.
[1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_vari...
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
Changes in v2:
- Drop using MSB of the object_id to distingush kernel and user object invoke contexts.
- Introduce enum tee_object_invoke_origin to check the context of object invocation.
- Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659...
Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients
Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver
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 +++++++
I don't see any changes to the QSEECOM drivers. Is it allowed to use QSEECOM and QTEE access to uefisecapp at the same time?
drivers/tee/qcomtee/call.c | 205 ++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 33 deletions(-)
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014
Best regards,
Harshal Dev harshal.dev@oss.qualcomm.com
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.
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.
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#L44...
It is a work in progress. Once this happens, we don't need QTEE supplicant available on the Linux distribution.
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 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.
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_...
On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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.
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/728251fcbe5113980805ea6c5... 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.
The next planned firmware upgrade for Hamoa will also provide this support for Qualcomm Linux. And similarly, for all other targets being supported upstream.
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.
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
Regards, Harshal
This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example.
Merge Strategy:
This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch.
[1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_vari...
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
Changes in v2:
- Drop using MSB of the object_id to distingush kernel and user object invoke contexts.
- Introduce enum tee_object_invoke_origin to check the context of object invocation.
- Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659...
Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients
Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver
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 +++++++
I don't see any changes to the QSEECOM drivers. Is it allowed to use QSEECOM and QTEE access to uefisecapp at the same time?
drivers/tee/qcomtee/call.c | 205 ++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 33 deletions(-)
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014
Best regards,
Harshal Dev harshal.dev@oss.qualcomm.com
Hi Dmitry,
A gentle reminder, do let me know you opinion on my comments here. I plan to spin a v3 once we're aligned on any open points.
Thanks, Harshal
On 24-07-2026 02:43 pm, 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.
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.
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#L44...
It is a work in progress. Once this happens, we don't need QTEE supplicant available on the Linux distribution.
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 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.
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_...
On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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.
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/728251fcbe5113980805ea6c5... 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.
The next planned firmware upgrade for Hamoa will also provide this support for Qualcomm Linux. And similarly, for all other targets being supported upstream.
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.
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
Regards, Harshal
This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example.
Merge Strategy:
This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch.
[1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_vari...
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
Changes in v2:
- Drop using MSB of the object_id to distingush kernel and user object invoke contexts.
- Introduce enum tee_object_invoke_origin to check the context of object invocation.
- Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659...
Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients
Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver
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 +++++++
I don't see any changes to the QSEECOM drivers. Is it allowed to use QSEECOM and QTEE access to uefisecapp at the same time?
drivers/tee/qcomtee/call.c | 205 ++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 33 deletions(-)
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014
Best regards,
Harshal Dev harshal.dev@oss.qualcomm.com
Hi Dmitry,
Gentle Reminder.
Thanks, Harshal
On 03-08-2026 08:22 pm, Harshal Dev wrote:
Hi Dmitry,
A gentle reminder, do let me know you opinion on my comments here. I plan to spin a v3 once we're aligned on any open points.
Thanks, Harshal
On 24-07-2026 02:43 pm, 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.
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.
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#L44...
It is a work in progress. Once this happens, we don't need QTEE supplicant available on the Linux distribution.
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 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.
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_...
On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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.
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/728251fcbe5113980805ea6c5... 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.
The next planned firmware upgrade for Hamoa will also provide this support for Qualcomm Linux. And similarly, for all other targets being supported upstream.
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.
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
Regards, Harshal
This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example.
Merge Strategy:
This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch.
[1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_vari...
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
Changes in v2:
- Drop using MSB of the object_id to distingush kernel and user object invoke contexts.
- Introduce enum tee_object_invoke_origin to check the context of object invocation.
- Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f659...
Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients
Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver
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 +++++++
I don't see any changes to the QSEECOM drivers. Is it allowed to use QSEECOM and QTEE access to uefisecapp at the same time?
drivers/tee/qcomtee/call.c | 205 ++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 33 deletions(-)
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014
Best regards,
Harshal Dev harshal.dev@oss.qualcomm.com
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.
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#L44...
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.
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.
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_...
Does it support QTEE-based uefi variable storage?
On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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?
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.
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/728251fcbe5113980805ea6c5... 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?
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.
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.
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.
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#L44...
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_...
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:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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/728251fcbe5113980805ea6c5... 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/5590c1dc631827624c110df28...
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
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#L44...
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_...
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:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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/728251fcbe5113980805ea6c5... 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/5590c1dc631827624c110df28...
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
Hello Dmitry,
A gentle reminder. Hopefully we can align on below points and move to a v3 of this series.
Regards, Harshal
On 17-08-2026 11:54 am, Harshal Dev wrote:
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#L44...
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_...
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:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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/728251fcbe5113980805ea6c5... 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/5590c1dc631827624c110df28...
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
Hi Dmitry,
Gentle Reminder.
Regards, Harshal
On 21-08-2026 02:04 pm, Harshal Dev wrote:
Hello Dmitry,
A gentle reminder. Hopefully we can align on below points and move to a v3 of this series.
Regards, Harshal
On 17-08-2026 11:54 am, Harshal Dev wrote:
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#L44...
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_...
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/728251fcbe5113980805ea6c5... 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/5590c1dc631827624c110df28...
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
On Wed, Aug 12, 2026 at 05:00:27PM +0530, Harshal Dev via OP-TEE wrote:
Hi Dmitry,
Hi Harshal, please excuse the huge delay from my side, I was on vacation and then burried under the rest of the issues.
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#L44...
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.
So, this must be fixed, I assume? What is the ETA?
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. :)
Let me be very explicit here. The path used by Windows is tested and verified to work on a plethora of the devices. Those devices must work with Linux too, so, in my opinion, we should use the same firmware path and the same firmware interfaces as used by Windows.
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_...
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.
Can't we fix the QSEECOM instead, if one needs to flash another release anyways?
On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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.
My understanding was that QTEE path completely disables the QSEECOM path, does it not?
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.
My opinion is very obvious by now. Existing devices should work. _Must_ work. They provide the reference interface. Make them work first and work good. Then explain, why the other interface is better (I fail to see it from your cover letter or from any of the commit messages).
When I take a Glumur laptop from the market shelf, will it be QSEECOM or QCOMTEE? If I take the next-generation-after-Glymur, will QTEE interface for uefisecapp be supported there? Will it be used by Windows?
I think the series fails to answer, why do we need another mechanism, if we already have one which has been working for the past N years and which is supposed to work for another M years?
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.
So, I'd say, the series is strange. We are proposing something which is not rolled out, which is not supported by the exsiting commercial devices, etc. On the other hand we have future gaps which are known. This doesn't sound correctly.
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/728251fcbe5113980805ea6c5... 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
Why do we need to switch the app? Why is the old one worth switching?
needs to be consumed for it: https://github.com/qualcomm-linux/meta-qcom/commit/5590c1dc631827624c110df28...
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
What stopped us from delivering the TZ apps compatible with the existing interface?
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.
I don't see a difference. You are saying that the list implementation is good, it silintly skips the unavailable services, etc., and then you say that you don't have to keep maintaining the list.
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.
To look forward, we need to have a good firm stand on the ground. We have a half-baked implementation, based on reverse engineering. No RPMB support, etc.
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.
What will happen if I build both and boot the kernel on the existing devices?
Hi Dmitry,
On 29-08-2026 08:19 pm, Dmitry Baryshkov wrote:
On Wed, Aug 12, 2026 at 05:00:27PM +0530, Harshal Dev via OP-TEE wrote:
Hi Dmitry,
Hi Harshal, please excuse the huge delay from my side, I was on vacation and then burried under the rest of the issues.
Ahh I was not aware, I hope you had a good vacation 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#L44...
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.
So, this must be fixed, I assume? What is the ETA?
I agree, it will have to be a separate effort. If new firmware QTEE releases are not being rolled out for these existing WoA devices, and if their RPMB exists on UFS/eMMC then the only way to support EFI variable is to: 1. Add support for callback requests in the upstream QSEECOM driver. 2. Add support for RPMB listener in kernel which routes the RPMB frames from QTEE to the RPMB device via the QSEECOM driver.
This is significant effort for supporting a protocol which is deprecated on the QTEE side moving forward. That being said, I do not discourage this effort. We can think of a plan if we really want to support these devices. I will be happy to engage.
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. :)
Let me be very explicit here. The path used by Windows is tested and verified to work on a plethora of the devices. Those devices must work with Linux too, so, in my opinion, we should use the same firmware path
Agreed, as mentioned above, we can think of a plan to support these devices by extending the QSEECOM driver.
and the same firmware interfaces as used by Windows.
The interfaces used on Windows by the TrEE driver are different as per the information I obtained from Windows team. But we don't need to worry about that, we already have QSEECOM in upstream which we can extend.
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_...
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.
Can't we fix the QSEECOM instead, if one needs to flash another release anyways?
QSEECOM is deprecated, requesting support for fixing it is an overhead at this point. Even if we take the time to fix it ourselves, it won't help, because the QSEECOM driver doesn't support callback requests and a path to the RPMB device within the Linux kernel.
On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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.
My understanding was that QTEE path completely disables the QSEECOM path, does it not?
By 'QTEE path', I believe you mean the 'QCOMTEE/SMCInvoke' protocol path.
No, both SMCInvoke/QCOMTEE and QSEECOM paths can be supported simultaneously within QTEE. QTEE does not disable the QSEECOM path when it enables the SMCInvoke/QCOMTEE one.
You can have both QSEECOM and SMCInvoke clients running together on a Qualcomm platform. QTEE doesn't impose any restrictions. The control/data paths within QTEE for these two protocols are completely isolated from each other.
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.
My opinion is very obvious by now. Existing devices should work. _Must_ work. They provide the reference interface. Make them work first and work good. Then explain, why the other interface is better (I fail to see it from your cover letter or from any of the commit messages).
When I take a Glumur laptop from the market shelf, will it be QSEECOM or QCOMTEE? If I take the next-generation-after-Glymur, will QTEE interface for uefisecapp be supported there? Will it be used by Windows?
I think the series fails to answer, why do we need another mechanism, if we already have one which has been working for the past N years and which is supposed to work for another M years?
At this point, we have the following categories of devices: 1. Devices with only QSEECOM support, but no support for callbacks/RPMB listener within Linux QSEECOM driver. Example, MSM8998 and older WoA laptops. These are very old devices (at least more than 6-7 years old).
2. Devices with both QSEECOM and SMCInvoke/QCOMTEE support. Example, SM8650, *Glymur*. These are relatively new devices (2-5 years old).
3. Devices with only SMCInvoke/QCOMTEE support. Example, RB3Gen2/Kodiak, IQ-9075/LeMans and newer devices which might not have QSEECOM support in the future since QTEE team has deprecated QSEECOM.
This patch series helps devices in category 2 and 3. Without the mechanism introduced by this series, we will end up in a situation where EFI variable based use-cases will become impossible on at least category 3 of devices. We must conform to the reality that QTEE firmware is transitioning to SMCInvoke as the protocol of choice with long-term committed support.
At the same time, I am aligned that we must think of a way to support devices in category 1 which is what you really care about. The QCOMTEE and QSEECOM drivers can co-exist, and so by adding support for both this patch series and callback requests to the QSEECOM driver (at a later point of time via a separate series) we will be able to provide EFI variable support on all Qualcomm platforms under the sun. This will accomplish our common goal.
I will add this information in the cover letter in a concise manner.
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.
So, I'd say, the series is strange. We are proposing something which is not rolled out, which is not supported by the exsiting commercial devices, etc. On the other hand we have future gaps which are known. This doesn't sound correctly.
We are proposing a mechanism which supports the majority of Qualcomm devices in the market launched within the last 5 years and also the upcoming ones. The category of devices which are not helped by this series are extremely old (at least 6+ years). Regardless, I am not pushing the view that we do not care about those devices, just that the route to helping them is different and orthogonal to this series and I am happy to engage on it separately.
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/728251fcbe5113980805ea6c5... 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
Why do we need to switch the app? Why is the old one worth switching?
You do not need to, Glymur supports both QSEECOM and QCOMTEE/SMCInvoke. I just used Glymur as an example to show that both work there and if a user wants he can chose one over the other (It really doesn't matter). Glymur sits in the middle of the old and the new, it is a category 2 device as mentioned above.
needs to be consumed for it: https://github.com/qualcomm-linux/meta-qcom/commit/5590c1dc631827624c110df28...
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
What stopped us from delivering the TZ apps compatible with the existing interface?
QSEECOM support is deprecated on IQ-9075 and broken on RB3Gen2.
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.
I don't see a difference. You are saying that the list implementation is good, it silintly skips the unavailable services, etc., and then you say that you don't have to keep maintaining the list.
We only have to add services to this list when a client driver appears for it. For example, this TPM series by Kuldeep: https://lore.kernel.org/all/20260831-tpm_qcom_driver-v1-1-6f16fa6924fa@oss.q...
We don't need to maintain this list on a per-platform basis unlike QSEECOM: https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/firmware/qcom/qcom_...
Support will arrive for dynamic detection, I have commitment from QTEE team for somewhere around end of the year. :)
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.
To look forward, we need to have a good firm stand on the ground. We have a half-baked implementation, based on reverse engineering. No RPMB support, etc.
Agreed. I am happy to engage on a separate series for adding callback support to QSEECOM driver along with RPMB listener within the kernel.
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.
What will happen if I build both and boot the kernel on the existing devices?
QSEECOM and its client driver probe first and establishes the path to uefisecapp for providing EFI variables service. QCOMTEE and its client silently fail probe.
Regards, Harshal
Hi Dmitry,
Gentle reminder. I am hoping we are aligned now.
Overall QSEECOM can be a separate effort for supporting older devices without SMCInvoke/QCOMTEE support. By moving forward with this series and with a separate one for QSEECOM, we will be able to support EFI variables on all Qualcomm platforms supported upstream.
Regards, Harshal
On 02-09-2026 01:41 pm, Harshal Dev wrote:
Hi Dmitry,
On 29-08-2026 08:19 pm, Dmitry Baryshkov wrote:
On Wed, Aug 12, 2026 at 05:00:27PM +0530, Harshal Dev via OP-TEE wrote:
Hi Dmitry,
Hi Harshal, please excuse the huge delay from my side, I was on vacation and then burried under the rest of the issues.
Ahh I was not aware, I hope you had a good vacation 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#L44...
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.
So, this must be fixed, I assume? What is the ETA?
I agree, it will have to be a separate effort. If new firmware QTEE releases are not being rolled out for these existing WoA devices, and if their RPMB exists on UFS/eMMC then the only way to support EFI variable is to:
- Add support for callback requests in the upstream QSEECOM driver.
- Add support for RPMB listener in kernel which routes the RPMB frames from QTEE to the RPMB device via the QSEECOM driver.
This is significant effort for supporting a protocol which is deprecated on the QTEE side moving forward. That being said, I do not discourage this effort. We can think of a plan if we really want to support these devices. I will be happy to engage.
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. :)
Let me be very explicit here. The path used by Windows is tested and verified to work on a plethora of the devices. Those devices must work with Linux too, so, in my opinion, we should use the same firmware path
Agreed, as mentioned above, we can think of a plan to support these devices by extending the QSEECOM driver.
and the same firmware interfaces as used by Windows.
The interfaces used on Windows by the TrEE driver are different as per the information I obtained from Windows team. But we don't need to worry about that, we already have QSEECOM in upstream which we can extend.
> 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_...
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.
Can't we fix the QSEECOM instead, if one needs to flash another release anyways?
QSEECOM is deprecated, requesting support for fixing it is an overhead at this point. Even if we take the time to fix it ourselves, it won't help, because the QSEECOM driver doesn't support callback requests and a path to the RPMB device within the Linux kernel.
> 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.
My understanding was that QTEE path completely disables the QSEECOM path, does it not?
By 'QTEE path', I believe you mean the 'QCOMTEE/SMCInvoke' protocol path.
No, both SMCInvoke/QCOMTEE and QSEECOM paths can be supported simultaneously within QTEE. QTEE does not disable the QSEECOM path when it enables the SMCInvoke/QCOMTEE one.
You can have both QSEECOM and SMCInvoke clients running together on a Qualcomm platform. QTEE doesn't impose any restrictions. The control/data paths within QTEE for these two protocols are completely isolated from each other.
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.
My opinion is very obvious by now. Existing devices should work. _Must_ work. They provide the reference interface. Make them work first and work good. Then explain, why the other interface is better (I fail to see it from your cover letter or from any of the commit messages).
When I take a Glumur laptop from the market shelf, will it be QSEECOM or QCOMTEE? If I take the next-generation-after-Glymur, will QTEE interface for uefisecapp be supported there? Will it be used by Windows?
I think the series fails to answer, why do we need another mechanism, if we already have one which has been working for the past N years and which is supposed to work for another M years?
At this point, we have the following categories of devices:
- Devices with only QSEECOM support, but no support for callbacks/RPMB listener within
Linux QSEECOM driver. Example, MSM8998 and older WoA laptops. These are very old devices (at least more than 6-7 years old).
- Devices with both QSEECOM and SMCInvoke/QCOMTEE support.
Example, SM8650, *Glymur*. These are relatively new devices (2-5 years old).
- Devices with only SMCInvoke/QCOMTEE support.
Example, RB3Gen2/Kodiak, IQ-9075/LeMans and newer devices which might not have QSEECOM support in the future since QTEE team has deprecated QSEECOM.
This patch series helps devices in category 2 and 3. Without the mechanism introduced by this series, we will end up in a situation where EFI variable based use-cases will become impossible on at least category 3 of devices. We must conform to the reality that QTEE firmware is transitioning to SMCInvoke as the protocol of choice with long-term committed support.
At the same time, I am aligned that we must think of a way to support devices in category 1 which is what you really care about. The QCOMTEE and QSEECOM drivers can co-exist, and so by adding support for both this patch series and callback requests to the QSEECOM driver (at a later point of time via a separate series) we will be able to provide EFI variable support on all Qualcomm platforms under the sun. This will accomplish our common goal.
I will add this information in the cover letter in a concise manner.
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.
So, I'd say, the series is strange. We are proposing something which is not rolled out, which is not supported by the exsiting commercial devices, etc. On the other hand we have future gaps which are known. This doesn't sound correctly.
We are proposing a mechanism which supports the majority of Qualcomm devices in the market launched within the last 5 years and also the upcoming ones. The category of devices which are not helped by this series are extremely old (at least 6+ years). Regardless, I am not pushing the view that we do not care about those devices, just that the route to helping them is different and orthogonal to this series and I am happy to engage on it separately.
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/728251fcbe5113980805ea6c5... 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
Why do we need to switch the app? Why is the old one worth switching?
You do not need to, Glymur supports both QSEECOM and QCOMTEE/SMCInvoke. I just used Glymur as an example to show that both work there and if a user wants he can chose one over the other (It really doesn't matter). Glymur sits in the middle of the old and the new, it is a category 2 device as mentioned above.
needs to be consumed for it: https://github.com/qualcomm-linux/meta-qcom/commit/5590c1dc631827624c110df28...
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
What stopped us from delivering the TZ apps compatible with the existing interface?
QSEECOM support is deprecated on IQ-9075 and broken on RB3Gen2.
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.
I don't see a difference. You are saying that the list implementation is good, it silintly skips the unavailable services, etc., and then you say that you don't have to keep maintaining the list.
We only have to add services to this list when a client driver appears for it. For example, this TPM series by Kuldeep: https://lore.kernel.org/all/20260831-tpm_qcom_driver-v1-1-6f16fa6924fa@oss.q...
We don't need to maintain this list on a per-platform basis unlike QSEECOM: https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/firmware/qcom/qcom_...
Support will arrive for dynamic detection, I have commitment from QTEE team for somewhere around end of the year. :)
> 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.
To look forward, we need to have a good firm stand on the ground. We have a half-baked implementation, based on reverse engineering. No RPMB support, etc.
Agreed. I am happy to engage on a separate series for adding callback support to QSEECOM driver along with RPMB listener within the kernel.
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.
What will happen if I build both and boot the kernel on the existing devices?
QSEECOM and its client driver probe first and establishes the path to uefisecapp for providing EFI variables service. QCOMTEE and its client silently fail probe.
Regards, Harshal
Hi Dmitry,
Another reminder. Please help with your comments on below. Hopefully we can move forward with suggested alignment.
Regards, Harshal
On 08-09-2026 02:57 pm, Harshal Dev wrote:
Hi Dmitry,
Gentle reminder. I am hoping we are aligned now.
Overall QSEECOM can be a separate effort for supporting older devices without SMCInvoke/QCOMTEE support. By moving forward with this series and with a separate one for QSEECOM, we will be able to support EFI variables on all Qualcomm platforms supported upstream.
Regards, Harshal
On 02-09-2026 01:41 pm, Harshal Dev wrote:
Hi Dmitry,
On 29-08-2026 08:19 pm, Dmitry Baryshkov wrote:
On Wed, Aug 12, 2026 at 05:00:27PM +0530, Harshal Dev via OP-TEE wrote:
Hi Dmitry,
Hi Harshal, please excuse the huge delay from my side, I was on vacation and then burried under the rest of the issues.
Ahh I was not aware, I hope you had a good vacation 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#L44...
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.
So, this must be fixed, I assume? What is the ETA?
I agree, it will have to be a separate effort. If new firmware QTEE releases are not being rolled out for these existing WoA devices, and if their RPMB exists on UFS/eMMC then the only way to support EFI variable is to:
- Add support for callback requests in the upstream QSEECOM driver.
- Add support for RPMB listener in kernel which routes the RPMB frames from QTEE to the RPMB device via the QSEECOM driver.
This is significant effort for supporting a protocol which is deprecated on the QTEE side moving forward. That being said, I do not discourage this effort. We can think of a plan if we really want to support these devices. I will be happy to engage.
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. :)
Let me be very explicit here. The path used by Windows is tested and verified to work on a plethora of the devices. Those devices must work with Linux too, so, in my opinion, we should use the same firmware path
Agreed, as mentioned above, we can think of a plan to support these devices by extending the QSEECOM driver.
and the same firmware interfaces as used by Windows.
The interfaces used on Windows by the TrEE driver are different as per the information I obtained from Windows team. But we don't need to worry about that, we already have QSEECOM in upstream which we can extend.
>> 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_...
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.
Can't we fix the QSEECOM instead, if one needs to flash another release anyways?
QSEECOM is deprecated, requesting support for fixing it is an overhead at this point. Even if we take the time to fix it ourselves, it won't help, because the QSEECOM driver doesn't support callback requests and a path to the RPMB device within the Linux kernel.
>> 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.
My understanding was that QTEE path completely disables the QSEECOM path, does it not?
By 'QTEE path', I believe you mean the 'QCOMTEE/SMCInvoke' protocol path.
No, both SMCInvoke/QCOMTEE and QSEECOM paths can be supported simultaneously within QTEE. QTEE does not disable the QSEECOM path when it enables the SMCInvoke/QCOMTEE one.
You can have both QSEECOM and SMCInvoke clients running together on a Qualcomm platform. QTEE doesn't impose any restrictions. The control/data paths within QTEE for these two protocols are completely isolated from each other.
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.
My opinion is very obvious by now. Existing devices should work. _Must_ work. They provide the reference interface. Make them work first and work good. Then explain, why the other interface is better (I fail to see it from your cover letter or from any of the commit messages).
When I take a Glumur laptop from the market shelf, will it be QSEECOM or QCOMTEE? If I take the next-generation-after-Glymur, will QTEE interface for uefisecapp be supported there? Will it be used by Windows?
I think the series fails to answer, why do we need another mechanism, if we already have one which has been working for the past N years and which is supposed to work for another M years?
At this point, we have the following categories of devices:
- Devices with only QSEECOM support, but no support for callbacks/RPMB listener within
Linux QSEECOM driver. Example, MSM8998 and older WoA laptops. These are very old devices (at least more than 6-7 years old).
- Devices with both QSEECOM and SMCInvoke/QCOMTEE support.
Example, SM8650, *Glymur*. These are relatively new devices (2-5 years old).
- Devices with only SMCInvoke/QCOMTEE support.
Example, RB3Gen2/Kodiak, IQ-9075/LeMans and newer devices which might not have QSEECOM support in the future since QTEE team has deprecated QSEECOM.
This patch series helps devices in category 2 and 3. Without the mechanism introduced by this series, we will end up in a situation where EFI variable based use-cases will become impossible on at least category 3 of devices. We must conform to the reality that QTEE firmware is transitioning to SMCInvoke as the protocol of choice with long-term committed support.
At the same time, I am aligned that we must think of a way to support devices in category 1 which is what you really care about. The QCOMTEE and QSEECOM drivers can co-exist, and so by adding support for both this patch series and callback requests to the QSEECOM driver (at a later point of time via a separate series) we will be able to provide EFI variable support on all Qualcomm platforms under the sun. This will accomplish our common goal.
I will add this information in the cover letter in a concise manner.
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.
So, I'd say, the series is strange. We are proposing something which is not rolled out, which is not supported by the exsiting commercial devices, etc. On the other hand we have future gaps which are known. This doesn't sound correctly.
We are proposing a mechanism which supports the majority of Qualcomm devices in the market launched within the last 5 years and also the upcoming ones. The category of devices which are not helped by this series are extremely old (at least 6+ years). Regardless, I am not pushing the view that we do not care about those devices, just that the route to helping them is different and orthogonal to this series and I am happy to engage on it separately.
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/728251fcbe5113980805ea6c5... 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
Why do we need to switch the app? Why is the old one worth switching?
You do not need to, Glymur supports both QSEECOM and QCOMTEE/SMCInvoke. I just used Glymur as an example to show that both work there and if a user wants he can chose one over the other (It really doesn't matter). Glymur sits in the middle of the old and the new, it is a category 2 device as mentioned above.
needs to be consumed for it: https://github.com/qualcomm-linux/meta-qcom/commit/5590c1dc631827624c110df28...
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
What stopped us from delivering the TZ apps compatible with the existing interface?
QSEECOM support is deprecated on IQ-9075 and broken on RB3Gen2.
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.
I don't see a difference. You are saying that the list implementation is good, it silintly skips the unavailable services, etc., and then you say that you don't have to keep maintaining the list.
We only have to add services to this list when a client driver appears for it. For example, this TPM series by Kuldeep: https://lore.kernel.org/all/20260831-tpm_qcom_driver-v1-1-6f16fa6924fa@oss.q...
We don't need to maintain this list on a per-platform basis unlike QSEECOM: https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/firmware/qcom/qcom_...
Support will arrive for dynamic detection, I have commitment from QTEE team for somewhere around end of the year. :)
>> 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.
To look forward, we need to have a good firm stand on the ground. We have a half-baked implementation, based on reverse engineering. No RPMB support, etc.
Agreed. I am happy to engage on a separate series for adding callback support to QSEECOM driver along with RPMB listener within the kernel.
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.
What will happen if I build both and boot the kernel on the existing devices?
QSEECOM and its client driver probe first and establishes the path to uefisecapp for providing EFI variables service. QCOMTEE and its client silently fail probe.
Regards, Harshal
On Wed, Sep 02, 2026 at 01:41:54PM +0530, Harshal Dev wrote:
Hi Dmitry,
On 29-08-2026 08:19 pm, Dmitry Baryshkov wrote:
On Wed, Aug 12, 2026 at 05:00:27PM +0530, Harshal Dev via OP-TEE wrote:
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#L44...
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.
So, this must be fixed, I assume? What is the ETA?
I agree, it will have to be a separate effort. If new firmware QTEE releases are not being rolled out for these existing WoA devices, and if their RPMB exists on UFS/eMMC then the only way to support EFI variable is to:
- Add support for callback requests in the upstream QSEECOM driver.
- Add support for RPMB listener in kernel which routes the RPMB frames from QTEE to the RPMB device via the QSEECOM driver.
This is significant effort for supporting a protocol which is deprecated on the QTEE side moving forward. That being said, I do not discourage this effort. We can think of a plan if we really want to support these devices. I will be happy to engage.
Why woudln't we want to support the existing devices on the market side? I think this boils down to a few questions. See below (where we discuss three kinds of platforms).
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. :)
Let me be very explicit here. The path used by Windows is tested and verified to work on a plethora of the devices. Those devices must work with Linux too, so, in my opinion, we should use the same firmware path
Agreed, as mentioned above, we can think of a plan to support these devices by extending the QSEECOM driver.
and the same firmware interfaces as used by Windows.
The interfaces used on Windows by the TrEE driver are different as per the information I obtained from Windows team. But we don't need to worry about that, we already have QSEECOM in upstream which we can extend.
Also added to the question below.
> 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_...
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.
Can't we fix the QSEECOM instead, if one needs to flash another release anyways?
QSEECOM is deprecated, requesting support for fixing it is an overhead at this point. Even if we take the time to fix it ourselves, it won't help, because the QSEECOM driver doesn't support callback requests and a path to the RPMB device within the Linux kernel.
Why is it deprecated? Maybe it would have been a good start for the 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.
My understanding was that QTEE path completely disables the QSEECOM path, does it not?
By 'QTEE path', I believe you mean the 'QCOMTEE/SMCInvoke' protocol path.
No, both SMCInvoke/QCOMTEE and QSEECOM paths can be supported simultaneously within QTEE. QTEE does not disable the QSEECOM path when it enables the SMCInvoke/QCOMTEE one.
You can have both QSEECOM and SMCInvoke clients running together on a Qualcomm platform. QTEE doesn't impose any restrictions. The control/data paths within QTEE for these two protocols are completely isolated from each other.
Okay, that's nice. Thanks.
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.
My opinion is very obvious by now. Existing devices should work. _Must_ work. They provide the reference interface. Make them work first and work good. Then explain, why the other interface is better (I fail to see it from your cover letter or from any of the commit messages).
When I take a Glumur laptop from the market shelf, will it be QSEECOM or QCOMTEE? If I take the next-generation-after-Glymur, will QTEE interface for uefisecapp be supported there? Will it be used by Windows?
I think the series fails to answer, why do we need another mechanism, if we already have one which has been working for the past N years and which is supposed to work for another M years?
At this point, we have the following categories of devices:
- Devices with only QSEECOM support, but no support for callbacks/RPMB listener within
Linux QSEECOM driver. Example, MSM8998 and older WoA laptops. These are very old devices (at least more than 6-7 years old).
- Devices with both QSEECOM and SMCInvoke/QCOMTEE support.
Example, SM8650, *Glymur*. These are relatively new devices (2-5 years old).
Where do SC8280XP and Hamoa / Purwa devices fall into? Is it #1 or #2? What about WoA laptops for the next platform after Glymur?
Also, the standard worry is that even if they implement QCOMTEE path in addition to QSEECOM it might be less tested. That's why beforehand I pointed out that it's imporant to use the same path as Windows do.
- Devices with only SMCInvoke/QCOMTEE support.
Example, RB3Gen2/Kodiak, IQ-9075/LeMans and newer devices which might not have QSEECOM support in the future since QTEE team has deprecated QSEECOM.
This patch series helps devices in category 2 and 3. Without the mechanism introduced by this series, we will end up in a situation where EFI variable based use-cases will become impossible on at least category 3 of devices. We must conform to the reality that QTEE firmware is transitioning to SMCInvoke as the protocol of choice with long-term committed support.
At the same time, I am aligned that we must think of a way to support devices in category 1 which is what you really care about. The QCOMTEE and QSEECOM drivers can co-exist, and so by adding support for both this patch series and callback requests to the QSEECOM driver (at a later point of time via a separate series) we will be able to provide EFI variable support on all Qualcomm platforms under the sun. This will accomplish our common goal.
Ok. Let me take as an example the set of devices that (some of) my colleagues and I use on a daily bases for our work: Lenovo X13s (SC8280XP), Lenovo T14s (Hamoa), Lenovo Yoga Slim7x2 (Glymur). What will be the effect of the series on those devices? If they switch to QCOMTEE to provide EFI variables, how well tested is that path?
X13s were produced 3-4 years ago, T14s are even newer.
I will add this information in the cover letter in a concise manner.
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.
So, I'd say, the series is strange. We are proposing something which is not rolled out, which is not supported by the exsiting commercial devices, etc. On the other hand we have future gaps which are known. This doesn't sound correctly.
We are proposing a mechanism which supports the majority of Qualcomm devices in the market launched within the last 5 years and also the upcoming ones. The category of devices which are not helped by this series are extremely old (at least 6+ years). Regardless, I am not pushing the view that we do not care about those devices, just that the route to helping them is different and orthogonal to this series and I am happy to engage on it separately.
Ok. So, I assume Glymur+1 will also use QCOMTEE on Windows side to access EFI vars?
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/728251fcbe5113980805ea6c5... 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
Why do we need to switch the app? Why is the old one worth switching?
You do not need to, Glymur supports both QSEECOM and QCOMTEE/SMCInvoke. I just used Glymur as an example to show that both work there and if a user wants he can chose one over the other (It really doesn't matter). Glymur sits in the middle of the old and the new, it is a category 2 device as mentioned above.
needs to be consumed for it: https://github.com/qualcomm-linux/meta-qcom/commit/5590c1dc631827624c110df28...
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
What stopped us from delivering the TZ apps compatible with the existing interface?
QSEECOM support is deprecated on IQ-9075 and broken on RB3Gen2.
That's not really an answer to 'what stopped us from delivering a working solution' question. I think it boils down to the 'why was QSEECOM' deprecated question.
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.
I don't see a difference. You are saying that the list implementation is good, it silintly skips the unavailable services, etc., and then you say that you don't have to keep maintaining the list.
We only have to add services to this list when a client driver appears for it. For example, this TPM series by Kuldeep: https://lore.kernel.org/all/20260831-tpm_qcom_driver-v1-1-6f16fa6924fa@oss.q...
We don't need to maintain this list on a per-platform basis unlike QSEECOM: https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/firmware/qcom/qcom_...
Support will arrive for dynamic detection, I have commitment from QTEE team for somewhere around end of the year. :)
Ok, thanks for the explanation. For the reference, if listener interface was implemented, we could have dropped the QSEECOM list too, only keeping the broken entries there.
> 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.
To look forward, we need to have a good firm stand on the ground. We have a half-baked implementation, based on reverse engineering. No RPMB support, etc.
Agreed. I am happy to engage on a separate series for adding callback support to QSEECOM driver along with RPMB listener within the kernel.
Nice, let's continue in this direction while this series lands (we have started the discussion internally some time ago, but I didn't have time to finish the listener study).
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.
What will happen if I build both and boot the kernel on the existing devices?
QSEECOM and its client driver probe first and establishes the path to uefisecapp for providing EFI variables service. QCOMTEE and its client silently fail probe.
I hope you mean here that UEFI variables client fails to probe.
Hi Dmitry,
On 16-09-2026 06:47 pm, Dmitry Baryshkov wrote:
On Wed, Sep 02, 2026 at 01:41:54PM +0530, Harshal Dev wrote:
Hi Dmitry,
On 29-08-2026 08:19 pm, Dmitry Baryshkov wrote:
On Wed, Aug 12, 2026 at 05:00:27PM +0530, Harshal Dev via OP-TEE wrote:
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#L44...
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.
So, this must be fixed, I assume? What is the ETA?
I agree, it will have to be a separate effort. If new firmware QTEE releases are not being rolled out for these existing WoA devices, and if their RPMB exists on UFS/eMMC then the only way to support EFI variable is to:
- Add support for callback requests in the upstream QSEECOM driver.
- Add support for RPMB listener in kernel which routes the RPMB frames from QTEE to the RPMB device via the QSEECOM driver.
This is significant effort for supporting a protocol which is deprecated on the QTEE side moving forward. That being said, I do not discourage this effort. We can think of a plan if we really want to support these devices. I will be happy to engage.
Why woudln't we want to support the existing devices on the market side? I think this boils down to a few questions. See below (where we discuss three kinds of platforms).
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. :)
Let me be very explicit here. The path used by Windows is tested and verified to work on a plethora of the devices. Those devices must work with Linux too, so, in my opinion, we should use the same firmware path
Agreed, as mentioned above, we can think of a plan to support these devices by extending the QSEECOM driver.
and the same firmware interfaces as used by Windows.
The interfaces used on Windows by the TrEE driver are different as per the information I obtained from Windows team. But we don't need to worry about that, we already have QSEECOM in upstream which we can extend.
Also added to the question below.
>> 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_...
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.
Can't we fix the QSEECOM instead, if one needs to flash another release anyways?
QSEECOM is deprecated, requesting support for fixing it is an overhead at this point. Even if we take the time to fix it ourselves, it won't help, because the QSEECOM driver doesn't support callback requests and a path to the RPMB device within the Linux kernel.
Why is it deprecated? Maybe it would have been a good start for the cover letter.
I agree, I can understand the whole disconnect here is why use SMCInvoke/QCOMTEE instead of QSEECOM. I will ensure this is explained better in the cover letter.
To answer your question, QSEECOM was deprecated because its design wasn't scalable to support multiple use-cases on-top of the same protocol. Implying that whenever a new use-case arrived which had to talk to QTEE, we would need to add a new ioctl() into the downstream driver coupled with a new SCM call into QTEE. So the driver implementation quickly became bloated, instead of just handling transport/communication with QTEE, it started becoming a place for use-cases owners to add their use-case specific code. This resulted in frequent stability issues on both the QTEE and Linux side and the protocol became a nightmare to maintain.
You can already see symptoms of this in the current upstream QSEECOM driver, we are using an SCM call just to get the app_id of the TA we are communicating with: https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/firmware/qcom/qcom_... There is a separate QSEECOM SCM call in QTEE if we want to provision RPMB, and a separate one if we want to get the information for crypto pipes mapped by QTEE and so on..
Contrast this with SMCInvoke/QCOMTEE where everything can be accomplished with just 2 SCM calls: https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/tee/qcomtee/core.c#... We can keep adding new TEE client drivers for QCOMTEE, without the need for any new SCM calls.
As long as we limit the use-cases we have on QSEECOM, things will remain manageable. The unfortunately reality, as you have highlighted is that there remain devices in the market whose firmware cannot be upgraded to support SMCInvoke/QCOMTEE, and if we want to support a use-case like EFI variables on that, we need to continue with QSEECOM. But let's ensure we don't make this a habit for every use-case. We should take a stand that QSEECOM will only be supported for legacy chipsets.
>> 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.
My understanding was that QTEE path completely disables the QSEECOM path, does it not?
By 'QTEE path', I believe you mean the 'QCOMTEE/SMCInvoke' protocol path.
No, both SMCInvoke/QCOMTEE and QSEECOM paths can be supported simultaneously within QTEE. QTEE does not disable the QSEECOM path when it enables the SMCInvoke/QCOMTEE one.
You can have both QSEECOM and SMCInvoke clients running together on a Qualcomm platform. QTEE doesn't impose any restrictions. The control/data paths within QTEE for these two protocols are completely isolated from each other.
Okay, that's nice. Thanks.
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.
My opinion is very obvious by now. Existing devices should work. _Must_ work. They provide the reference interface. Make them work first and work good. Then explain, why the other interface is better (I fail to see it from your cover letter or from any of the commit messages).
When I take a Glumur laptop from the market shelf, will it be QSEECOM or QCOMTEE? If I take the next-generation-after-Glymur, will QTEE interface for uefisecapp be supported there? Will it be used by Windows?
I think the series fails to answer, why do we need another mechanism, if we already have one which has been working for the past N years and which is supposed to work for another M years?
At this point, we have the following categories of devices:
- Devices with only QSEECOM support, but no support for callbacks/RPMB listener within
Linux QSEECOM driver. Example, MSM8998 and older WoA laptops. These are very old devices (at least more than 6-7 years old).
- Devices with both QSEECOM and SMCInvoke/QCOMTEE support.
Example, SM8650, *Glymur*. These are relatively new devices (2-5 years old).
Where do SC8280XP and Hamoa / Purwa devices fall into? Is it #1 or #2? What about WoA laptops for the next platform after Glymur?
All 3 call fall into category 2. However, SC8280XP is pretty old, and so the SMCInvoke/QCOMTEE path there might be a little less mature. I remember you mentioned that the QTEE versioning service did not work on this: https://github.com/qualcomm/minkipc/issues/56
Also, the standard worry is that even if they implement QCOMTEE path in addition to QSEECOM it might be less tested. That's why beforehand I pointed out that it's imporant to use the same path as Windows do.
This is only a worry for SC8280XP, but anyways since no new firmware releases are going for this, we cannot use SMCInvoke/QCOMTEE here for uefisecapp, we'll have to stick to QSEECOM. For Hamoa/Purwa the SMCInvoke/QCOMTEE interface is extremely stable since they are pretty new.
I want to re-iterate that for Windows there is a completely different TrEE protocol which the Windows OS implements. I have no insight into that protocol, and so writing a driver from scratch for that for Linux based on reverse engineering is not possible. Let's stick to developing QSEECOM, since we know how that one works.
- Devices with only SMCInvoke/QCOMTEE support.
Example, RB3Gen2/Kodiak, IQ-9075/LeMans and newer devices which might not have QSEECOM support in the future since QTEE team has deprecated QSEECOM.
This patch series helps devices in category 2 and 3. Without the mechanism introduced by this series, we will end up in a situation where EFI variable based use-cases will become impossible on at least category 3 of devices. We must conform to the reality that QTEE firmware is transitioning to SMCInvoke as the protocol of choice with long-term committed support.
At the same time, I am aligned that we must think of a way to support devices in category 1 which is what you really care about. The QCOMTEE and QSEECOM drivers can co-exist, and so by adding support for both this patch series and callback requests to the QSEECOM driver (at a later point of time via a separate series) we will be able to provide EFI variable support on all Qualcomm platforms under the sun. This will accomplish our common goal.
Ok. Let me take as an example the set of devices that (some of) my colleagues and I use on a daily bases for our work: Lenovo X13s (SC8280XP), Lenovo T14s (Hamoa), Lenovo Yoga Slim7x2 (Glymur). What will be the effect of the series on those devices? If they switch to QCOMTEE to provide EFI variables, how well tested is that path?
X13s were produced 3-4 years ago, T14s are even newer.
uefisecapp TA used by both QSEECOM and SMCInvoke/QCOMTEE is exactly the same. The only difference is in the protocol which hands control to the TA. I have already validated Glymur with this patch series. There is zero delta in terms of the TA code/transport protocol between Hamoa/Glymur, so it will work there as well.
X13s cannot be helped with this patch series because no new QTEE firmware which enables the SMCInvoke path for it is being rolled out.
But, as I mentioned (at the very end of this thread) we don't want to disturb the clients working fine with QSEECOM. The TEE client driver will fail probe if QSEECOM uefisecapp driver succeeds in registering EFI var.
I will add this information in the cover letter in a concise manner.
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.
So, I'd say, the series is strange. We are proposing something which is not rolled out, which is not supported by the exsiting commercial devices, etc. On the other hand we have future gaps which are known. This doesn't sound correctly.
We are proposing a mechanism which supports the majority of Qualcomm devices in the market launched within the last 5 years and also the upcoming ones. The category of devices which are not helped by this series are extremely old (at least 6+ years). Regardless, I am not pushing the view that we do not care about those devices, just that the route to helping them is different and orthogonal to this series and I am happy to engage on it separately.
Ok. So, I assume Glymur+1 will also use QCOMTEE on Windows side to access EFI vars?
I cannot comment on Windows OS, they have their own TrEE downstream driver as per my information. Compute devices like Glymur+ booting Linux distros can work with existing QSEECOM since it has emulated RPMB not requiring a callback request.
For other devices moving forward, with new QTEE firmware versions, we should migrate to QCOMTEE/SMCInvoke since that is the protocol with committed long term support. For older devices without emulated RPMB, we can develop the QSEECOM driver to provide EFI variables support as you have correctly highlighted in this thread.
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/728251fcbe5113980805ea6c5... 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
Why do we need to switch the app? Why is the old one worth switching?
You do not need to, Glymur supports both QSEECOM and QCOMTEE/SMCInvoke. I just used Glymur as an example to show that both work there and if a user wants he can chose one over the other (It really doesn't matter). Glymur sits in the middle of the old and the new, it is a category 2 device as mentioned above.
needs to be consumed for it: https://github.com/qualcomm-linux/meta-qcom/commit/5590c1dc631827624c110df28...
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
What stopped us from delivering the TZ apps compatible with the existing interface?
QSEECOM support is deprecated on IQ-9075 and broken on RB3Gen2.
That's not really an answer to 'what stopped us from delivering a working solution' question. I think it boils down to the 'why was QSEECOM' deprecated question.
Answered above.
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.
I don't see a difference. You are saying that the list implementation is good, it silintly skips the unavailable services, etc., and then you say that you don't have to keep maintaining the list.
We only have to add services to this list when a client driver appears for it. For example, this TPM series by Kuldeep: https://lore.kernel.org/all/20260831-tpm_qcom_driver-v1-1-6f16fa6924fa@oss.q...
We don't need to maintain this list on a per-platform basis unlike QSEECOM: https://elixir.bootlin.com/linux/v7.2-rc7/source/drivers/firmware/qcom/qcom_...
Support will arrive for dynamic detection, I have commitment from QTEE team for somewhere around end of the year. :)
Ok, thanks for the explanation. For the reference, if listener interface was implemented, we could have dropped the QSEECOM list too, only keeping the broken entries there.
Yes, with a listener interface, this can be sorted.
>> 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.
To look forward, we need to have a good firm stand on the ground. We have a half-baked implementation, based on reverse engineering. No RPMB support, etc.
Agreed. I am happy to engage on a separate series for adding callback support to QSEECOM driver along with RPMB listener within the kernel.
Nice, let's continue in this direction while this series lands (we have started the discussion internally some time ago, but I didn't have time to finish the listener study).
Sure, let's do it. I believe you are now fine with me spinning a v3 of this series now. Thanks for all the valuable feedback and discussions.
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.
What will happen if I build both and boot the kernel on the existing devices?
QSEECOM and its client driver probe first and establishes the path to uefisecapp for providing EFI variables service. QCOMTEE and its client silently fail probe.
I hope you mean here that UEFI variables client fails to probe.
Yes that is what I meant. :)
Regards, Harshal
On 22-07-2026 12:29, 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 Secure Application to the RPMB service running in user-space (within the QTEE supplicant [1]).
Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current QSEECOM based uefisecapp) 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 Qualcomm TEE. On these platforms, a TEE based uefisecapp client driver is required to:
- Access cached & volatile EFI variables stored in uefisecapp's memory.
- 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.
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.
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.
Signed-off-by: Harshal Dev harshal.dev@oss.qualcomm.com
+Jarkko too.
Hi Dmitry, Amirreza and Jens, Can we have alignment on patches 1-5 of this series? Please note, 1-5 are needed for tpm_qcom series[1] merger and since tpm series is reviewed so checking if we can proceed with 1-5 atleast and keep patch 6/6 discussion separate?
[1] https://lore.kernel.org/lkml/20260907-tpm_qcom_driver-v2-0-71a6b1752da8@oss....
op-tee@lists.trustedfirmware.org
-
Amirreza Zarrabi -
Dmitry Baryshkov -
Harshal Dev -
Kuldeep Singh