- OP-TEE - lists.trustedfirmware.org

[PATCH v2 0/2] rpmb: add virtio RPMB driver

by Haruka Kuze

This adds a driver on top of the rpmb subsystem for virtio-rpmb devices. Alex Bennée had an earlier virtio-rpmb driver in his RPMB series [1] but that stalled due to the user space API. The one that merged later has no user space API and OP-TEE routes frames through it so this driver only needs to implement route_frames(). I added patch 1 to fix a use-after-free that I hit while testing removing the device (OP-TEE can still route frames after driver unregisters the rpmb device). I tested this with UML (virtio_uml) and a vhost-user backend I wrote for this on top of rust-vmm's vhost-device with KASAN, lockdep: - key programming - write counter - single and multi block write and read - MAC and counter failures - max_wr_cnt - unbinding the driver when the rpmb device is held With OP-TEE 4.11 on QEMU virt arm64 the secure_storage example TA keeps its objects in RPMB through the driver and an object written to in one boot is found in the one after. I have added myself in MAINTAINERS. I would like to maintain the driver. Changes in v2: - Use guard() and scoped_guard() for the locks in both patches (Greg) - Call virtio_device_ready() before vr->vq is set, so a request on restore can not kick the queue before DRIVER_OK (sashiko) - v1: https://lore.kernel.org/all/20261029081317.2264887-1-harukak@zohomail.eu/ - haruka [1] https://lore.kernel.org/all/20220405093759.1126835-1-alex.bennee@linaro.org/ Haruka Kuze (2): rpmb: stop the routing after unregister rpmb: add a virtio RPMB device driver MAINTAINERS | 7 + drivers/misc/Kconfig | 10 ++ drivers/misc/Makefile | 1 + drivers/misc/rpmb-core.c | 14 +- drivers/misc/virtio_rpmb.c | 286 +++++++++++++++++++++++++++++++ include/linux/rpmb.h | 4 + include/uapi/linux/virtio_rpmb.h | 56 ++++++ 7 files changed, 377 insertions(+), 1 deletion(-) create mode 100644 drivers/misc/virtio_rpmb.c create mode 100644 include/uapi/linux/virtio_rpmb.h base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8 -- 2.55.0

5 days, 15 hours

1
2
0 0

[PATCH 0/2] rpmb: add virtio RPMB driver

by Haruka Kuze

This adds a driver on top of the rpmb subsystem for virtio-rpmb devices. Alex Bennée had an earlier virtio-rpmb driver in his RPMB series [1] but that stalled due to the user space API. The one that merged later has no user space API and OP-TEE routes frames through it so this driver only needs to implement route_frames(). I added patch 1 to fix a use-after-free that I hit while testing removing the device (OP-TEE can still route frames after driver unregisters the rpmb device). I tested this with UML (virtio_uml) and a vhost-user backend I wrote for this on top of rust-vmm's vhost-device with KASAN, lockdep: - key programming - write counter - single and multi block write and read - MAC and counter failures - max_wr_cnt - unbinding the driver when the rpmb device is held With OP-TEE 4.11 on QEMU virt arm64 the secure_storage example TA keeps its objects in RPMB through the driver and an object written to in one boot is found in the one after. I have added myself in MAINTAINERS. I would like to maintain the driver. - haruka [1] https://lore.kernel.org/all/20220405093759.1126835-1-alex.bennee@linaro.org/ Haruka Kuze (2): rpmb: stop the routing after unregister rpmb: add a virtio RPMB device driver MAINTAINERS | 7 + drivers/misc/Kconfig | 10 ++ drivers/misc/Makefile | 1 + drivers/misc/rpmb-core.c | 22 ++- drivers/misc/virtio_rpmb.c | 294 +++++++++++++++++++++++++++++++ include/linux/rpmb.h | 4 + include/uapi/linux/virtio_rpmb.h | 56 ++++++ 7 files changed, 391 insertions(+), 3 deletions(-) create mode 100644 drivers/misc/virtio_rpmb.c create mode 100644 include/uapi/linux/virtio_rpmb.h base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8 -- 2.55.0

5 days, 18 hours

2
3
0 0

[PATCH v10] media: qcom: Pass proper PAS ID to set_remote_state API

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> As per testing the SCM backend just ignores it while OP-TEE makes use of it to for proper book keeping purpose. Reviewed-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> # Lemans Reviewed-by: Vikash Garodia <vikash.garodia(a)oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio(a)oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg(a)oss.qualcomm.com> --- Changes in v10: - Resent standalone, as all the earlier patches of the series are merged. - Link to v9: https://lore.kernel.org/all/20260702115835.167602-11-sumit.garg@kernel.org/ --- drivers/media/platform/qcom/iris/iris_firmware.c | 2 +- drivers/media/platform/qcom/venus/firmware.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c index 21f57d37da18..ed2bd0e83797 100644 --- a/drivers/media/platform/qcom/iris/iris_firmware.c +++ b/drivers/media/platform/qcom/iris/iris_firmware.c @@ -262,5 +262,5 @@ int iris_fw_unload(struct iris_core *core) int iris_set_hw_state(struct iris_core *core, bool resume) { - return qcom_pas_set_remote_state(resume, 0); + return qcom_pas_set_remote_state(resume, IRIS_PAS_ID); } diff --git a/drivers/media/platform/qcom/venus/firmware.c b/drivers/media/platform/qcom/venus/firmware.c index 3a38ff985822..3c0727ea137d 100644 --- a/drivers/media/platform/qcom/venus/firmware.c +++ b/drivers/media/platform/qcom/venus/firmware.c @@ -59,7 +59,7 @@ int venus_set_hw_state(struct venus_core *core, bool resume) int ret; if (core->use_tz) { - ret = qcom_pas_set_remote_state(resume, 0); + ret = qcom_pas_set_remote_state(resume, VENUS_PAS_ID); if (resume && ret == -EINVAL) ret = 0; return ret; --- base-commit: d135ab453a7400a34930bdda1ef4bdc8acfac80e change-id: 20261027-pas-id-media-7cc70fc5716f Best regards, -- Sumit Garg <sumit.garg(a)oss.qualcomm.com>

1 week

2
1
0 0

[PATCH v2] tee: shm: don't warn on oversized request in tee_dyn_shm_alloc_helper()

by Georgiy Osokin

tee_dyn_shm_alloc_helper() passes the size from TEE_IOC_SHM_ALLOC to alloc_pages_exact(), which needs one physically contiguous block. A size above 4 MiB (MAX_PAGE_ORDER with 4 KiB pages) is more than the page allocator can serve, so it trips its order warning; on a panic_on_warn kernel that is a panic. The size comes from userspace and the request fails with -ENOMEM anyway, so pass __GFP_NOWARN. Fixes: abd135ba215c ("tee: optee: add optee-specific shared pool implementation") Cc: stable(a)vger.kernel.org Cc: lvc-project(a)linuxtesting.org Signed-off-by: Georgiy Osokin <g.osokin(a)auroraos.dev> --- v2: Fixes now points to abd135ba215c, the commit that introduced the unchecked allocation; cf4441503e20 only moved the code. v1: https://lore.kernel.org/all/20261026105209.161195-1-g.osokin@auroraos.dev/ drivers/tee/tee_shm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index daa4af1..8b117d6 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -352,7 +352,7 @@ int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align, * and there's no need for any larger alignment. */ shm->kaddr = alloc_pages_exact(nr_pages * PAGE_SIZE, - GFP_KERNEL | __GFP_ZERO); + GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN); if (!shm->kaddr) return -ENOMEM; -- 2.54.0

1 week, 1 day

1
0
0 0

[PATCH] tee: shm: don't warn on oversized request in tee_dyn_shm_alloc_helper()

by Georgiy Osokin

tee_dyn_shm_alloc_helper() passes the size from TEE_IOC_SHM_ALLOC to alloc_pages_exact(), which needs one physically contiguous block. A size above 4 MiB (MAX_PAGE_ORDER with 4 KiB pages) is more than the page allocator can serve, so it trips its order warning; on a panic_on_warn kernel that is a panic. The size comes from userspace and the request fails with -ENOMEM anyway, so pass __GFP_NOWARN. Fixes: cf4441503e20 ("tee: optee: Move pool_op helper functions") Cc: stable(a)vger.kernel.org Cc: lvc-project(a)linuxtesting.org Signed-off-by: Georgiy Osokin <g.osokin(a)auroraos.dev> --- drivers/tee/tee_shm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c index daa4af1..8b117d6 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -352,7 +352,7 @@ int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align, * and there's no need for any larger alignment. */ shm->kaddr = alloc_pages_exact(nr_pages * PAGE_SIZE, - GFP_KERNEL | __GFP_ZERO); + GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN); if (!shm->kaddr) return -ENOMEM; -- 2.54.0

1 week, 1 day

1
0
0 0

[RFC PATCH] tee: optee: allow forcing the reserved shared memory pool

by christian.koever-draxl＠student.uibk.ac.at

From: Christian Stefan Kövér-Draxl <ckoever(a)outlook.de> The X98Q's vendor BL32 runs OP-TEE 3.8 and reports sec_caps 0x5, that is HAVE_RESERVED_SHM | DYNAMIC_SHM, with neither UNREGISTERED_SHM nor RPC_ARG. For that combination optee_probe() picks the dynamic pool and sets OPTEE_SHM_ARG_ALLOC_PRIV, so every message argument is an unregistered private page passed to secure world by physical address via OPTEE_SMC_CALL_WITH_ARG. This OP-TEE will not accept that: every call comes back OPTEE_SMC_RETURN_EBADADDR (4), which optee_open_session() converts into TEEC_ERROR_COMMUNICATION / TEEC_ORIGIN_COMMS. The result is that no session can be opened at all - not to the Amlogic firmware loading PTA the video decoder needs, and not to any built-in PTA either. Registering memory works fine, and HAVE_RESERVED_SHM is set, so the existing static pool path is usable. Add optee.no_dyn_shm to select it. With the reserved pool the device enumeration PTA opens cleanly and the system PTA answers with its own ACCESS_DENIED, so the ABI is healthy. The driver arguably should not use unregistered arguments unless secure world advertised UNREGISTERED_SHM; a parameter keeps the change local until that is confirmed upstream. Signed-off-by: Christian Stefan Kövér-Draxl <ckoever(a)outlook.de> --- Tool use (Documentation/process/generated-content.rst): This work was done with the help of an AI coding assistant, Claude (Anthropic), used through Claude Code over many sessions. It did a large part of the hands-on work: it read the vendor kernel and the firmware interfaces, probed registers on the board, drafted the code and the changelogs, and ran the builds, checkpatch, dt_binding_check and the tests on the hardware. I directed the work, reviewed every change and the final patches, and take responsibility for them. There is no single prompt to quote; the sessions were of the form "find out why X fails on this board, fix it, test it on the box". Tested on an Amediatech X98Q TV box (Amlogic S905W2, S4 family, 2 GiB), vendor U-Boot and BL31/OP-TEE, Linux 7.3 plus this work. drivers/tee/optee/smc_abi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c index 51624443359b..1824aead78a6 100644 --- a/drivers/tee/optee/smc_abi.c +++ b/drivers/tee/optee/smc_abi.c @@ -34,6 +34,11 @@ #define CREATE_TRACE_POINTS #include "optee_trace.h" +static bool optee_no_dyn_shm; +module_param_named(no_dyn_shm, optee_no_dyn_shm, bool, 0444); +MODULE_PARM_DESC(no_dyn_shm, + "Ignore the secure world's dynamic shared memory capability and use the reserved pool instead"); + /* * This file implement the SMC ABI used when communicating with secure world * OP-TEE OS via raw SMCs. @@ -1770,7 +1775,7 @@ static int optee_probe(struct platform_device *pdev) /* * Try to use dynamic shared memory if possible */ - if (sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) { + if ((sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM) && !optee_no_dyn_shm) { /* * If we have OPTEE_SMC_SEC_CAP_RPC_ARG we can ask * optee_get_msg_arg() to pre-register (by having base-commit: 7be4bc52fd9e0e55dc9a2e0232b89427d2c4b614 -- 2.56.0

1 week, 2 days

1
0
0 0

OP-TEE Contributions Forum, monthly meeting October 27

by Jens Wiklander

Hi, On Tuesday next week, it's time for another OP-TEE contributors' monthly meeting. For time and connection details, see the calendar at https://www.trustedfirmware.org/meetings/ We've released OP-TEE version 4.11.0 :-) MbedTLS end-of-life April 2027: https://lists.trustedfirmware.org/archives/list/mbed-tls@lists.trustedfirmw… No urgent action needed. We can stick with MbedTLS for now, but we can't maintain it. CI updates and the way forward: - Replaced the branch push trigger with a nightly CI job and a CI status badge in the README.md - Switch and renovate CI image https://github.com/OP-TEE/optee_os/pull/8021 I pushed the patches to a ci_testing branch in optee_os to give it a spin and to generate the needed ci-image. Rebased optee out-of-tree kernel patches on v7.3 optee_client for Zephyr, etc. https://github.com/OP-TEE/optee_client/issues/428 Any other topic? Cheers, Jens

1 week, 5 days

1
0
0 0

Rebased optee branch @ linaro-swg/kernel to v7.3

by Jens Wiklander

Hi, With the release out, it's a good time for changes. I've just rebased the optee branch @ linaro-swg/kernel onto the latest kernel, v7.3. Please let me know if there are any issues. The old branch is reachable from the signed optee-4.11.0 tag. Cheers, Jens

1 week, 6 days

1
0
0 0

[PATCH] tee: optee: allocate a bitmap for all valid notification keys

by Amirreza Zarrabi

Notification keys are checked against an inclusive maximum, but optee_notif_init() passes that maximum to bitmap_zalloc() as the number of bits. The bitmap is therefore one bit short. When the maximum key is a multiple of BITS_PER_LONG, accessing that key reads or writes beyond the allocated bitmap. Word rounding masks the problem. Allocate max_key + 1 bits so that the highest valid key has storage. Fixes: 787c80cc7b22 ("optee: separate notification functions") Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> --- drivers/tee/optee/notif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/notif.c b/drivers/tee/optee/notif.c index 68014222d7be..2bf5ce397233 100644 --- a/drivers/tee/optee/notif.c +++ b/drivers/tee/optee/notif.c @@ -114,7 +114,7 @@ int optee_notif_init(struct optee *optee, u_int max_key) { spin_lock_init(&optee->notif.lock); INIT_LIST_HEAD(&optee->notif.db); - optee->notif.bitmap = bitmap_zalloc(max_key, GFP_KERNEL); + optee->notif.bitmap = bitmap_zalloc(max_key + 1, GFP_KERNEL); if (!optee->notif.bitmap) return -ENOMEM; --- base-commit: becb95e45ef0dda9ffb35156d909d3da7a2789c3 change-id: 20261009-fix-tee-max-keys-50f2db87b4e5 Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

2 weeks, 1 day

2
1
0 0

[PATCH v3 0/3] Add TPM support via Qualcomm TEE TPM TA

by Kuldeep Singh

Qualcomm platforms with a discrete TPM (dTPM) talked to it directly over a non-secure SPI channel from the kernel. Arm's Base Boot Security Requirements (BBSR) v1.4 require that access to go through TrustZone instead, so on affected Qualcomm platforms the TPM 2.0 instance is now fronted by a Trusted Application (TA) running inside Qualcomm's Trusted Execution Environment (QTEE), which talks to the dTPM (or implements an fTPM) on the kernel's behalf. This series adds a kernel driver for that TA, built on the QCOMTEE object-IPC transport (drivers/tee/qcomtee/) already used to reach other QTEE services. This patch series functionally depends on below(first 5 changes specially) for qtee service discovery. - https://lore.kernel.org/lkml/20261006-qcom_uefisecapp_migrate_qcomtee-v4-0-… Tested on Glymur-crd target with tpm2-tools utility. Validations: - Get capabilities - Random number generator - RSA key creation, encryption and decryption. Signed-off-by: Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com> --- Changes in v3: - Merge tpm_qcom.h into tpm_qcom.c(Amir comments) - Update return values of functions and drop certain error prints. - Define locality_arg as default value. - Add Jarrko's tag on all but drop from 2/3 as significant changes done. - Link to v2: https://patch.msgid.link/20260907-tpm_qcom_driver-v2-0-71a6b1752da8@oss.qua… Changes in v2: - Use QCOMTEE_TPM_UID as 81 for service discovery in patch 1. - Use FIELD_GET, zero initialised array and log improvement (Konrad) - Improve commit title and other fixes (Jarkko) - Split MAINTAINERS entry as separate patch. - Link to v1: https://patch.msgid.link/20260831-tpm_qcom_driver-v1-0-6f16fa6924fa@oss.qua… To: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> To: Jens Wiklander <jenswi(a)kernel.org> To: Sumit Garg <sumit.garg(a)kernel.org> To: Peter Huewe <peterhuewe(a)gmx.de> To: Jarkko Sakkinen <jarkko(a)kernel.org> To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com> Cc: linux-arm-msm(a)vger.kernel.org Cc: op-tee(a)lists.trustedfirmware.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-integrity(a)vger.kernel.org --- Kuldeep Singh (3): tee: qcomtee: Register qcom.tz.tpm service for discovery tpm: Introduce Qualcomm TPM driver MAINTAINERS: Add Qualcomm TPM driver entry MAINTAINERS | 6 + drivers/char/tpm/Kconfig | 9 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_qcom.c | 413 ++++++++++++++++++++++++++++++++++++++ drivers/tee/qcomtee/call.c | 4 +- drivers/tee/qcomtee/qcomtee_msg.h | 2 + 6 files changed, 434 insertions(+), 1 deletion(-) --- base-commit: d419d682257d813f6cb7a28e42b35d0edf4ad038 change-id: 20260831-tpm_qcom_driver-d21c720e73b2 prerequisite-change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014:v4 prerequisite-patch-id: faf4520d818abf0d7533f71d9c8b9a8aade34626 prerequisite-patch-id: b487dfe2fbc076f4815dc6c73b9e68b0b78c961f prerequisite-patch-id: aef7dba7d7662f87cb06bbf5cabca93304843f02 prerequisite-patch-id: bbdd5327c15aeaa99ce9b74bab324a98f084ed48 prerequisite-patch-id: 6263a8a3b40df5cce7fbe4b119f4b9d67a4c06b4 prerequisite-patch-id: 0c1a650a54014eb20f7ab9ec20038b49e42680e1 prerequisite-patch-id: 7be993abea2ca36057d9352381a5890f50996dda Best regards, -- Kuldeep Singh <kuldsing(a)qti.qualcomm.com>

2 weeks, 1 day

2
7
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE