- OP-TEE - lists.trustedfirmware.org

OP-TEE 4.11.0 release (June 17) cancelled

by Jens Wiklander

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE version 4.11.0 was initially planned for release on 2026-06-17. When we discussed this in the OP-TEE contributors forum today, we agreed to cancel it, as none of the core maintainers are available during the release cycle. We will schedule the 4.11.0 release on 2026-10-16 instead. I'm updating the release page accordingly: https://optee.readthedocs.io/en/latest/general/releases.html The corresponding PR is: https://github.com/OP-TEE/optee_docs/pull/287 Thanks for your understanding, and we'll be back in touch as the new date approaches. Cheers, Jens

6 hours, 6 minutes

1
0
0 0

[RFC 0/3] core: riscv: Implement Floating-Point and Vector extension context tracking

by dave.patel＠riscstar.com

From: Dave Patel <dave.patel(a)riscstar.com> Dear OP-TEE Developers, This proposal introduces architectural runtime context management structures and tracking mechanisms for standard scalar Floating-Point (F/D) and Vector (V) ISA extensions on RISC-V platforms. ### 1. Architectural Alignment and Shift Currently, the thread scheduling layer in OP-TEE OS implements a tightly coupled VFP model specific to the ARM architecture (e.g., thread_kernel_enable_vfp). This model relies heavily on a software driven "lazy context trap" mechanism, where the kernel disables the FPU to catch subsequent execution faults. On RISC-V architectures, context tracking cannot rely on software initiated lazy traps via execution faults due to structural opcode overlap across custom extensions and the severe pipeline execution penalties of traps. Instead, RISC-V provides native hardware status state machines managed via the `sstatus.FS` (Floating-Point) and `sstatus.VS` (Vector) bitfields. To map seamlessly into OP-TEE's existing `thread_*_vfp` thread scheduling, we utilize these hardware flags to implement "eager-on-dirty" context saving. The kernel leaves extensions enabled during active execution and only write at context switch if the hardware reports a `Dirty` status. ### 2. Implementation Subsystem Architecture To maintain modular design the implementation explicitly divides scalar processing from scalable vector configurations: 1. Modularity & Headers: - <kernel/riscv_fp.h> specifies bitmasks and structures (`struct riscv_fp_state`) for scalar execution. - <kernel/riscv_vector.h> encapsulates scalable vector parameter state layouts (`struct riscv_vector_state`). This allows devices missing a vector unit to completely omit vector footprints or dependency. 2. Bitwidth and Layout Adaptability: - Scalar Low-Level Assembly (`fp_asm.S`): Natively adapts to both 32-bit (`rv32`) and 64-bit (`rv64`) width configurations via compiler `__riscv_xlen` preprocessing directives. - Vector Extension Optimization (`riscv_vector.c`): Fully isolated from primary thread files. Instead of storing vector registers sequentially, it adopts whole-register block transfer instructions (`vs8r.v` and `vl8r.v`). Grouping elements into blocks of eight compresses the save/restore pipeline into four core operational chunks (`v0`, `v8`, `v16`, `v24`). 3. Unified Scheduling Abstraction (`thread_vfp.c`): Unified top-level implementation (`thread_kernel_save_vfp`, `thread_user_enable_vfp`, etc.) are used for context routing. ### 3. Feedback Requested We are seeking early design feedback from the community regarding: - Structural Convention: Should we keep the universal "vfp" naming scheme within the global `thread.h` header interfaces for structural backward compatibility, or is an explicit upstream refactoring toward a generic name (e.g., `thread_kernel_enable_coproc_regs`) preferred? - Vector Bounds Memory Allocation: What is the preferred approach for safely managing the dynamic heap footprint for vector register states (`vregs`) which scale based on runtime CPU `VLENB` bounds? - Eager Context switching has been proposed, hence are there any reservations on this ? Looking forward to your suggestions and design critiques. Dave Patel (3): Floating Point changes RISCV Vector changes Thread changes for RISCV floating point and vector changes core/arch/riscv/include/riscv_fp.h | 30 +++++ core/arch/riscv/include/riscv_vector.h | 32 +++++ core/arch/riscv/kernel/riscv_fp.S | 159 +++++++++++++++++++++++++ core/arch/riscv/kernel/riscv_vector.c | 77 ++++++++++++ core/arch/riscv/kernel/thread_vfp.c | 142 ++++++++++++++++++++++ 5 files changed, 440 insertions(+) create mode 100644 core/arch/riscv/include/riscv_fp.h create mode 100644 core/arch/riscv/include/riscv_vector.h create mode 100644 core/arch/riscv/kernel/riscv_fp.S create mode 100644 core/arch/riscv/kernel/riscv_vector.c create mode 100644 core/arch/riscv/kernel/thread_vfp.c -- 2.43.0

9 hours, 49 minutes

1
3
0 0

[GIT PULL] TEE update for v7.2

by Jens Wiklander

Hello soc maintainers, Please pull this small patch updating my email address to a @kernel.org address. I lose access to my Linaro address next week. Thanks, Jens The following changes since commit 8cd9520d35a6c38db6567e97dd93b1f11f185dc6: Linux 7.1 (2026-06-14 15:58:38 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-update-for-v7.2 for you to fetch changes up to 314c243b201b678fa89226b1eaea51a71340454e: MAINTAINERS: .mailmap: update Jens Wiklander's email address (2026-06-22 15:24:51 +0200) ---------------------------------------------------------------- Update update Jens Wiklander's email address ---------------------------------------------------------------- Jens Wiklander (1): MAINTAINERS: .mailmap: update Jens Wiklander's email address .mailmap | 1 + MAINTAINERS | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-)

1 day, 2 hours

1
0
0 0

[PATCH v7 0/7] arm_ffa, KVM: Fix FF-A emad offset calculations

by Sebastian Ene

Hi all, This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations and adds the necessary bounds checks for both the core FF-A driver and the pKVM hypervisor. Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset for the EMADs, leading to the assumption that they immediately follow the header. However, from v1.1 onwards, the specification dictates using the ep_mem_offset` field to determine the start of the memory access array. The patches in this series address this by: 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`. It also introduces bounds checking against `max_fragsize`. 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that the descriptor strictly follows the header, aligning it with the driver behavior and the FF-A specification, while also ensuring the offset falls within the mailbox buffer bounds. While addressing these bugs, Sashiko uncovered other issues that were fixed in the same series. All the patches aside from the first one in optee are urgent fixes as they either impact the hypervisor security or kernel stability. Changelog ######### v6->v7: - taking the patches from Mostafa and sending a new version with the collected tags - Added overflow checks when doing `ep_offset + emad_size` in the arm ff-a driver - Move the length check before the ffa_mem_reclaim - fix compatibility break with ff-a version 1.0 reported by Sashiko - add one more patch to fix an issue with the FFA_VERSION call that can lead to leaking pKVM stack un-initialized data to a host when -ftrivial-auto-var-init=zero is not used. v5->v6: - Add fixes tag - Small clean up make variable declaration reverse christmas tree. v4->v5: - Collect Sudeep Rbs - Add extra patch to check base address alignment. - Remove WARN_ONs in KVM code - Use ffa_emad_size_get() instead of hardcoded size in KVM code. v3 -> v4: - Address review comments and fix Sashiko bugs v2 -> v3: - Fixed typo in nvhe/ffa.c (missing sizeof) v1 -> v2: - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not compliant with the spec, and avoids making assumptions about the driver's memory layout. Link to: ######## v6: https://lore.kernel.org/all/20260527150236.1978655-1-smostafa@google.com/ v5: https://lore.kernel.org/all/20260526151934.3783707-1-smostafa@google.com/ v4: https://lore.kernel.org/all/20260520204948.2440882-1-smostafa@google.com/ v3: https://lore.kernel.org/all/20260512124442.1899107-1-sebastianene@google.co… v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.co… v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t Mostafa Saleh (4): optee: ffa: Add NULL check in optee_ffa_lend_protmem firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() KVM: arm64: Ensure FFA ranges are page aligned Sebastian Ene (3): firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation KVM: arm64: Validate the offset to the mem access descriptor KVM: arm64: Zero out the stack initialized data in the FFA handler arch/arm64/kvm/hyp/nvhe/ffa.c | 47 ++++++++++++++++++++++--------- drivers/firmware/arm_ffa/driver.c | 25 ++++++++++------ drivers/tee/optee/ffa_abi.c | 3 ++ include/linux/arm_ffa.h | 2 +- 4 files changed, 54 insertions(+), 23 deletions(-) -- 2.54.0.1136.gdb2ca164c4-goog

1 day, 4 hours

2
13
0 0

OP-TEE Contributions Forum, monthly meeting June 23

by Jens Wiklander

Hi, Tomorrow, Tuesday, it's time for another OP-TEE contributors' monthly meeting. For time and connection details, see the calendar at https://www.trustedfirmware.org/meetings/ Maintainers in July: - Jens is unavailable most or all of July OP-TEE release July 17: - Someone needs to fill in for Jens, or we cancel or postpone the release Next OP-TEE Contributors Forum, July 28 - Can someone else host the meeting, or should we cancel it? Adding sections in MAINTAINERS - Core reviewers - Various TAs - Updating other parts Any updates for Kconfig support? Any other topics? Cheers, Jens

1 day, 8 hours

1
0
0 0

[PATCH v1] tee: qcomtee: Drop unused assignment of platform_device_id driver data

by Uwe Kleine-König (The Capable Hub)

The driver explicitly sets the .driver_data member of struct platform_device_id to zero without relying on that value. Drop this unused assignment. While touching this array unify spacing and usage of commas and use a named initializer for .name for improved readability. Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig(a)baylibre.com> --- Hello, while this is a cleanup that can stand on its own, it is also a preparation for a change to struct platform_device_id that requires that .driver_data isn't assigned by a list initializer. Best regards Uwe drivers/tee/qcomtee/call.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/tee/qcomtee/call.c b/drivers/tee/qcomtee/call.c index 0efc5646242a..4a597eeaf174 100644 --- a/drivers/tee/qcomtee/call.c +++ b/drivers/tee/qcomtee/call.c @@ -798,7 +798,12 @@ static void qcomtee_remove(struct platform_device *pdev) kfree(qcomtee); } -static const struct platform_device_id qcomtee_ids[] = { { "qcomtee", 0 }, {} }; +static const struct platform_device_id qcomtee_ids[] = { + { + .name = "qcomtee", + }, + { } +}; MODULE_DEVICE_TABLE(platform, qcomtee_ids); static struct platform_driver qcomtee_platform_driver = { base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac -- 2.47.3

1 week

1
0
0 0

Proposal to unify tf.org vulnerability referencing in NVD

by Sandrine Bailleux

Hi everyone, I am sending this email to all tf.org project mailing lists to ensure all maintainers are aware and on board regarding this matter. If you have any concerns or questions, please reply on tf.org Discord #general channel, where I'll create a thread, as I think it will be much easier than dealing with cross-mailing lists emails. Background When a security vulnerability is discovered in one of the trustedfirmware.org projects, it is common to request a "Common Vulnerabilities and Exposures" (CVE) number. This number uniquely references the issue, which can then be searched in the vulnerability databases. One of these databases is NIST's "National Vulnerability Database" (NVD): https://nvd.nist.gov<https://nvd.nist.gov/vuln/detail/CVE-2023-51712> Entering a specific CVE number in NVD search engine will allow you to easily find the details of a specific issue, for example: https://nvd.nist.gov/vuln/detail/CVE-2023-51712 However, sometimes one is not looking for a specific CVE number but rather wants to list all known vulnerabilities affecting a particular project. For this, one can use the Common Platform Enumerations (CPE) search engine: https://nvd.nist.gov/products/cpe/search CPE is a structured naming scheme that includes information like the vendor name, the project name, the version / tag, and so on. See https://nvd.nist.gov/products/cpe for more details. So for example, https://nvd.nist.gov/vuln/detail/CVE-2023-51712 referenced above has the following CPE: cpe:2.3:o:arm:trusted_firmware-m:*:*:*:*:*:*:*:* This basically means * CPE version 2.3 is in use * 'o is the type of project, in this case it stands for Operating Systems (which is probably the closest match for low-level code like TF-M) * 'arm' is the vendor (that is wrong, see below) * 'trusted_firmware-m' is the project name, Problem statement It appears that CPEs used in NVD to reference vulnerabilities in tf.org projects differ a lot across projects. For some projects, there's even multiple of them. Sometimes the vendor is "arm", sometimes it's "linaro", or something else. Some of the TF-A and MbedTLS maintainers have initiated discussions with NVD to get this simplified and unified, but it would make sense to align other tf.org projects as well. Proposal CPE naming rules are that the vendor name should the parent organization of the project. Thus the proposal would be for all tf.org projects to use "trustedfirmware" as the vendor name in their CPE. For example: cpe:2.3:o:trustedfirmware:trusted_firmware-m:*:*:*:*:*:*:*:* cpe:2.3:a:trustedfirmware:mbed_tls:*:*:*:*:*:*:*:* We're only proposing to change the vendor name here ; each project is then free to choose how they want the project name or the type of software project they want to encode there. Thanks for reading, Best regards, Sandrine Afsa

1 week, 1 day

1
1
0 0

[PATCH v6 0/6] arm_ffa, KVM: Fix FF-A emad offset calculations

by Mostafa Saleh

Hi all, This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations and adds the necessary bounds checks for both the core FF-A driver and the pKVM hypervisor. Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset for the EMADs, leading to the assumption that they immediately follow the header. However, from v1.1 onwards, the specification dictates using the ep_mem_offset` field to determine the start of the memory access array. The patches in this series address this by: 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`. It also introduces bounds checking against `max_fragsize`. 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that the descriptor strictly follows the header, aligning it with the driver behavior and the FF-A specification, while also ensuring the offset falls within the mailbox buffer bounds. While addressing these bugs, Sashiko uncovered other issues that were fixed in the same series. All the patches aside from the first one in optee are urgent fixes as they either impact the hypervisor security or kernel stability. Changelog ######### v5->v6: - Add fixes tag - Small clean up make variable declaration reverse christmas tree. v4->v5: - Collect Sudeep Rbs - Add extra patch to check base address alignment. - Remove WARN_ONs in KVM code - Use ffa_emad_size_get() instead of hardcoded size in KVM code. v3 -> v4: - Address review comments and fix Sashiko bugs v2 -> v3: - Fixed typo in nvhe/ffa.c (missing sizeof) v1 -> v2: - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not compliant with the spec, and avoids making assumptions about the driver's memory layout. Link to: ######## v5: https://lore.kernel.org/all/20260526151934.3783707-1-smostafa@google.com/ v4: https://lore.kernel.org/all/20260520204948.2440882-1-smostafa@google.com/ v3: https://lore.kernel.org/all/20260512124442.1899107-1-sebastianene@google.co… v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.co… v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t Mostafa Saleh (4): optee: ffa: Add NULL check in optee_ffa_lend_protmem firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() KVM: arm64: Ensure FFA ranges are page aligned Sebastian Ene (2): firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation KVM: arm64: Validate the offset to the mem access descriptor arch/arm64/kvm/hyp/nvhe/ffa.c | 38 ++++++++++++++++++++++--------- drivers/firmware/arm_ffa/driver.c | 21 ++++++++++------- drivers/tee/optee/ffa_abi.c | 3 +++ include/linux/arm_ffa.h | 2 +- 4 files changed, 44 insertions(+), 20 deletions(-) -- 2.54.0.746.g67dd491aae-goog

1 week, 4 days

3
11
0 0

[PATCH v5 0/6] arm_ffa, KVM: Fix FF-A emad offset calculations

by Mostafa Saleh

Hi all, This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations and adds the necessary bounds checks for both the core FF-A driver and the pKVM hypervisor. Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset for the EMADs, leading to the assumption that they immediately follow the header. However, from v1.1 onwards, the specification dictates using the ep_mem_offset` field to determine the start of the memory access array. The patches in this series address this by: 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`. It also introduces bounds checking against `max_fragsize`. 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that the descriptor strictly follows the header, aligning it with the driver behavior and the FF-A specification, while also ensuring the offset falls within the mailbox buffer bounds. While addressing these bugs, Sashiko uncovered other issues that were fixed in the same series. Changelog ######### v4->v5: - Collect Sudeep Rbs - Add extra patch to check base address alignment. - Remove WARN_ONs in KVM code - Use ffa_emad_size_get() instead of hardcoded size in KVM code. v3 -> v4: - Address review comments and fix Sashiko bugs v2 -> v3: - Fixed typo in nvhe/ffa.c (missing sizeof) v1 -> v2: - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not compliant with the spec, and avoids making assumptions about the driver's memory layout. Link to: ######## v4: https://lore.kernel.org/all/20260520204948.2440882-1-smostafa@google.com/ v3: https://lore.kernel.org/all/20260512124442.1899107-1-sebastianene@google.co… v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.co… v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t Mostafa Saleh (4): optee: ffa: Add NULL check in optee_ffa_lend_protmem firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() KVM: arm64: Ensure FFA ranges are page aligned Sebastian Ene (2): firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation KVM: arm64: Validate the offset to the mem access descriptor arch/arm64/kvm/hyp/nvhe/ffa.c | 38 ++++++++++++++++++++++--------- drivers/firmware/arm_ffa/driver.c | 21 ++++++++++------- drivers/tee/optee/ffa_abi.c | 3 +++ include/linux/arm_ffa.h | 2 +- 4 files changed, 44 insertions(+), 20 deletions(-) -- 2.54.0.746.g67dd491aae-goog

1 week, 4 days

3
9
0 0

[PATCH] MAINTAINERS: .mailmap: update Jens Wiklander's email address

by Jens Wiklander

From: Jens Wiklander <jenswi(a)kernel.org> Update Jens Wiklander's email address to @kernel.org. Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Sumit Garg <sumit.garg(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jens Wiklander <jenswi(a)kernel.org> --- .mailmap | 1 + MAINTAINERS | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/.mailmap b/.mailmap index a009f73d7ea5..a0f20a6bbe5c 100644 --- a/.mailmap +++ b/.mailmap @@ -395,6 +395,7 @@ Jens Axboe <axboe(a)kernel.dk> <jens.axboe(a)oracle.com> Jens Axboe <axboe(a)kernel.dk> <axboe(a)fb.com> Jens Axboe <axboe(a)kernel.dk> <axboe(a)meta.com> Jens Osterkamp <Jens.Osterkamp(a)de.ibm.com> +Jens Wiklander <jenswi(a)kernel.org> <jens.wiklander(a)linaro.org> Jernej Skrabec <jernej.skrabec(a)gmail.com> <jernej.skrabec(a)siol.net> Jesper Dangaard Brouer <hawk(a)kernel.org> <brouer(a)redhat.com> Jesper Dangaard Brouer <hawk(a)kernel.org> <hawk(a)comx.dk> diff --git a/MAINTAINERS b/MAINTAINERS index e035a3be797c..440f855b95df 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19958,7 +19958,7 @@ W: http://www.onsemi.com F: drivers/net/phy/ncn* OP-TEE DRIVER -M: Jens Wiklander <jens.wiklander(a)linaro.org> +M: Jens Wiklander <jenswi(a)kernel.org> L: op-tee(a)lists.trustedfirmware.org (moderated for non-subscribers) S: Maintained F: Documentation/ABI/testing/sysfs-bus-optee-devices @@ -23303,7 +23303,7 @@ F: Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml F: drivers/media/platform/sunxi/sun8i-rotate/ RPMB SUBSYSTEM -M: Jens Wiklander <jens.wiklander(a)linaro.org> +M: Jens Wiklander <jenswi(a)kernel.org> L: linux-kernel(a)vger.kernel.org S: Supported F: drivers/misc/rpmb-core.c @@ -26222,7 +26222,7 @@ F: drivers/media/i2c/tw9910.c F: include/media/i2c/tw9910.h TEE SUBSYSTEM -M: Jens Wiklander <jens.wiklander(a)linaro.org> +M: Jens Wiklander <jenswi(a)kernel.org> R: Sumit Garg <sumit.garg(a)kernel.org> L: op-tee(a)lists.trustedfirmware.org (moderated for non-subscribers) S: Maintained -- 2.43.0

2 weeks, 1 day

1
0
0 0

OP-TEE Contributions Forum, monthly meeting May 26

by Jens Wiklander

Hi, Tomorrow, Tuesday, it's time for another OP-TEE contributors' monthly meeting. For time and connection details, see the calendar at https://www.trustedfirmware.org/meetings/ Regarding Kconfig support:https://github.com/OP-TEE/optee_os/pull/7714 It appears that the transition will take quite some time. We'll have a window when some variables have transitioned to be managed by Kconfig, but others remain managed by the makefiles. Do we care that variables passed on the command line may work differently, depending on whether they are managed by makefiles or Kconfig? Can something be done about it? Any other topics? Cheers, Jens

2 weeks, 1 day

2
2
0 0

[GIT PULL] OP-TEE for v7.2

by Jens Wiklander

Hello soc maintainers, Please pull these two patches for the OP-TEE driver. Thanks, Jens The following changes since commit 028ef9c96e96197026887c0f092424679298aae8: Linux 7.0 (2026-04-12 13:48:06 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/optee-for-v7.2 for you to fetch changes up to 3faa6774ffc5973af39ac9c4f1fe93aa92ec9407: tee: optee: fix kernel-doc warnings (2026-04-27 14:13:14 +0200) ---------------------------------------------------------------- OP-TEE updates for 7.2 - Fix kernel-doc warnings in optee_private.h and optee_msg.h - Allow MT_NORMAL_TAGGED shared memory to support ARM64 MTE buffers ---------------------------------------------------------------- Hirokazu Honda (1): tee: optee: Allow MT_NORMAL_TAGGED shared memory Rodrigo Zaiden (1): tee: optee: fix kernel-doc warnings drivers/tee/optee/call.c | 3 +- drivers/tee/optee/optee_msg.h | 50 +++++++++------- drivers/tee/optee/optee_private.h | 120 ++++++++++++++++++++------------------ 3 files changed, 94 insertions(+), 79 deletions(-)

3 weeks, 4 days

1
0
0 0

[GIT PULL] AMD-TEE for v7.2

by Jens Wiklander

Hello soc maintainers, Please pull this cleanup patch for the AMD-TEE driver. Thanks, Jens The following changes since commit 028ef9c96e96197026887c0f092424679298aae8: Linux 7.0 (2026-04-12 13:48:06 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/amdtee-for-v7.2 for you to fetch changes up to 84a1e6179bd24dc10e47f6fa2b36f0ed345e68d8: tee: amdtee: store buffer ID in tee_shm->sec_world_id (2026-04-27 14:13:08 +0200) ---------------------------------------------------------------- AMD-TEE update for 7.2 Store buffer ID in tee_shm->sec_world_id and remove internal tracking structures to align with other TEE drivers ---------------------------------------------------------------- Rijo Thomas (1): tee: amdtee: store buffer ID in tee_shm->sec_world_id drivers/tee/amdtee/amdtee_private.h | 16 ------------ drivers/tee/amdtee/call.c | 2 +- drivers/tee/amdtee/core.c | 52 +++---------------------------------- 3 files changed, 5 insertions(+), 65 deletions(-)

3 weeks, 4 days

1
0
0 0

[PATCH v7 00/15] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#13: migrates all client drivers to generic PAS service. - Patch #14: drops legacy PAS SCM exported APIs. The patch-set is based on qcom tree tip [2] and can be found in git tree here [3]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged) [2] https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/log/?h=for-n… [3] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v7: - Rebased to qcom tree (for-next branch) tip. - Merged patch #5 and #7 due to build dependency. - Disabled modem for kodiak EL2 as it isn't tested yet. - Fix an issue found out by sashiko-bot for patch #4. Changes in v6: - Rebased to v7.1-rc4 tag. - Patch #14: fixed ret error print. - Add Kconfig descriptions for PAS symbols such that they are visible in menuconfig to update. Changes in v5: - Incorporated misc. comments from Mukesh. - Split up patch #11 into 2 to add an independent commit for passing proper PAS ID to set_remote_state API. - Picked up tags. Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (14): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs media: qcom: Pass proper PAS ID to set_remote_state API net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 39 ++ drivers/firmware/qcom/Kconfig | 21 +- drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 477 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 25 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 10 +- drivers/remoteproc/Kconfig | 4 +- drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 28 files changed, 1124 insertions(+), 320 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

3 weeks, 5 days

3
19
0 0

[PATCH v6 00/16] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#14: migrates all client drivers to generic PAS service. - Patch #15: drops legacy PAS SCM exported APIs. The patch-set is based on v7.1-rc4 tag and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged) [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v6: - Rebased to v7.1-rc4 tag. - Patch #14: fixed ret error print. - Add Kconfig descriptions for PAS symbols such that they are visible in menuconfig to update. Changes in v5: - Incorporated misc. comments from Mukesh. - Split up patch #11 into 2 to add an independent commit for passing proper PAS ID to set_remote_state API. - Picked up tags. Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (15): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs media: qcom: Pass proper PAS ID to set_remote_state API net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 21 +- drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 476 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 25 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 10 +- drivers/remoteproc/Kconfig | 4 +- drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 28 files changed, 1119 insertions(+), 320 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

1 month

4
22
0 0

dma_heap and protected memory

by Amirreza Zarrabi

Hi Jens, Recently protected heap support has been added for the TEE subsystem. This allows dma-heaps to be managed by the TEE subsystem itself. For standard, non-protected heaps such as the system heap or CMA heap, I am trying to understand the expected usage model. One possible workaround appears to be to mmap the dma-buf fd in userspace, then register the resulting userspace VA with the TEE subsystem to obtain a TEE shared-memory object, for example: fd = dma_heap_alloc(...); va = mmap(fd, ...); shm_fd = tee_shm_register(va, size); tee_invoke(shm_fd); close(shm_fd); munmap(va, size); close(fd); This seems reasonable when the lifetime of the registered shared memory is limited to a single invocation or callback. However, I am concerned about cases (multiple exits in qcomtee) where the TEE side needs to retain access to the memory after the ioctl/invocation returns. In that case, registering only the userspace VA does not appear to keep the underlying dma-buf object alive. The TEE core pins the pages, but it does not hold a dma-buf reference or attachment. If userspace later closes the dma-buf fd and unmaps the VA, the dma-buf exporter may consider the buffer released, while the TEE side may still have the memory registered. Is there a recommended way to use standard heaps, such as the system or CMA dma-buf heaps, when the sharing lifetime is longer than a single TEE call? Would it make sense to extend tee_shm_register_fd() so that it can handle dma-buf fds from regular dma-heaps as well, not only dma-bufs managed by the TEE subsystem? That would allow the TEE core or backend driver to keep the dma-buf reference for the lifetime of the TEE shared-memory object. Best regards, Amir

1 month

3
4
0 0

[GIT PULL] QCOMTEE fix for v7.1

by Jens Wiklander

Hello soc maintainers, Please pull this small fix for the QCOMTEE driver. Thanks, Jens The following changes since commit 028ef9c96e96197026887c0f092424679298aae8: Linux 7.0 (2026-04-12 13:48:06 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/qcomtee-fix-for-v7.1 for you to fetch changes up to 471c18323dfdfe7844e193b896a9267ae23a1026: tee: qcomtee: add missing va_end in early return qcomtee_object_user_init() (2026-05-20 09:22:52 +0200) ---------------------------------------------------------------- QCOMTEE fix for v7.1 Adding a missing va_end in early return qcomtee_object_user_init() ---------------------------------------------------------------- Robertus Diawan Chris (1): tee: qcomtee: add missing va_end in early return qcomtee_object_user_init() drivers/tee/qcomtee/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)

1 month

1
0
0 0

[GIT PULL] OP-TEE fix for v7.1

by Jens Wiklander

Hello soc maintainers, Please pull this patch fixing a use-after-free race in the OP-TEE driver where a client exiting prematurely could free a request still being processed by the supplicant. This is basically a resend of https://lore.kernel.org/op-tee/20260316071210.GA2470832@rayden/ Thanks, Jens The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f: Linux 7.0-rc1 (2026-02-22 13:18:59 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/optee-fix-for-v7.1 for you to fetch changes up to 387a926ee166814611acecb960207fe2f3c4fd3e: tee: optee: prevent use-after-free when the client exits before the supplicant (2026-03-02 14:36:50 +0100) ---------------------------------------------------------------- OP-TEE fix for v7.1 Prevent possible use after free in supplicant communication. ---------------------------------------------------------------- Amirreza Zarrabi (1): tee: optee: prevent use-after-free when the client exits before the supplicant drivers/tee/optee/supp.c | 107 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 74 insertions(+), 33 deletions(-)

1 month

1
0
0 0

[GIT PULL] TEE fixes for v7.1

by Jens Wiklander

Hello soc maintainers, Please pull these small fixes for the TEE subsystem. Thanks, Jens The following changes since commit 028ef9c96e96197026887c0f092424679298aae8: Linux 7.0 (2026-04-12 13:48:06 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-fixes-for-v7.1 for you to fetch changes up to 6fa9b543f6b4ed15ff72af266b29f316643de289: tee: fix params_from_user() error path in tee_ioctl_supp_recv (2026-05-20 08:49:09 +0200) ---------------------------------------------------------------- TEE fixes for v7.1 Fixing: - params_from_user() cleanup in error path in tee_ioctl_supp_recv() - possible tee_shm leak in error path in register_shm_helper() - padding in struct tee_ioctl_object_invoke_arg ---------------------------------------------------------------- Arnd Bergmann (1): tee: fix tee_ioctl_object_invoke_arg padding Georgiy Osokin (1): tee: shm: fix shm leak in register_shm_helper() Qihang (1): tee: fix params_from_user() error path in tee_ioctl_supp_recv drivers/tee/tee_core.c | 56 +++++++++++++++++++++--------------------------- drivers/tee/tee_shm.c | 2 +- include/uapi/linux/tee.h | 1 + 3 files changed, 27 insertions(+), 32 deletions(-)

1 month

1
0
0 0

[PATCH v4 0/5] arm_ffa, KVM: Fix FF-A emad offset calculations

by Mostafa Saleh

Hi all, This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations and adds the necessary bounds checks for both the core FF-A driver and the pKVM hypervisor. Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset for the EMADs, leading to the assumption that they immediately follow the header. However, from v1.1 onwards, the specification dictates using the ep_mem_offset` field to determine the start of the memory access array. The patches in this series address this by: 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`. It also introduces bounds checking against `max_fragsize`. 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that the descriptor strictly follows the header, aligning it with the driver behavior and the FF-A specification, while also ensuring the offset falls within the mailbox buffer bounds. While addressing these bugs, Sashiko uncovered other issues that were fixed in the same series. Changelog ######### v3 -> v4: - Address review comments and fix Sashiko bugs v2 -> v3: - Fixed typo in nvhe/ffa.c (missing sizeof) v1 -> v2: - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not compliant with the spec, and avoids making assumptions about the driver's memory layout. Link to: ######## v3: https://lore.kernel.org/all/20260512124442.1899107-1-sebastianene@google.co… v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.co… v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t Mostafa Saleh (3): optee: ffa: Add NULL check in optee_ffa_lend_protmem firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit() KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim() Sebastian Ene (2): firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset calculation KVM: arm64: Validate the offset to the mem access descriptor arch/arm64/kvm/hyp/nvhe/ffa.c | 30 +++++++++++++++++++++++------- drivers/firmware/arm_ffa/driver.c | 21 +++++++++++++-------- drivers/tee/optee/ffa_abi.c | 3 +++ include/linux/arm_ffa.h | 2 +- 4 files changed, 40 insertions(+), 16 deletions(-) -- 2.54.0.669.g59709faab0-goog

1 month

3
11
0 0

[PATCH v2] tee: qcomtee: add missing va_end in early return qcomtee_object_user_init()

by Robertus Diawan Chris

qcomtee_object_user_init() is a variadic function and when the function return because there's no dispatch callback in QCOMTEE_OBJECT_TYPE_CB case, there's no va_end to cleanup "ap" object initialized by va_start and that can cause undefined behavior. So make sure to use va_end before returning the error code when there's no dispatch callback. This is reported by Coverity Scan as "Missing varargs init or cleanup". Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Signed-off-by: Robertus Diawan Chris <robertusdchris(a)gmail.com> Reviewed-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> --- v1 -> v2: - Use "break" statement instead of "goto" statement. There's va_end outside of switch-case, so we only need to go out from switch-case instead of using a label (suggested by Amirreza Zarrabi). - Add "Reviewed-by" tag from Amirreza Zarrabi. v1: https://lore.kernel.org/all/20260513091031.145826-1-robertusdchris@gmail.co… I don't have the device, so I am not sure how to test this change. Thank you. drivers/tee/qcomtee/core.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/tee/qcomtee/core.c b/drivers/tee/qcomtee/core.c index b1cb50e434f0..60fe3b5776e3 100644 --- a/drivers/tee/qcomtee/core.c +++ b/drivers/tee/qcomtee/core.c @@ -306,8 +306,10 @@ int qcomtee_object_user_init(struct qcomtee_object *object, break; case QCOMTEE_OBJECT_TYPE_CB: object->ops = ops; - if (!object->ops->dispatch) - return -EINVAL; + if (!object->ops->dispatch) { + ret = -EINVAL; + break; + } /* If failed, "no-name". */ object->name = kvasprintf_const(GFP_KERNEL, fmt, ap); base-commit: 5200f5f493f79f14bbdc349e402a40dfb32f23c8 -- 2.54.0

1 month

2
1
0 0

[PATCH] tee: qcomtee: add missing va_end in early return qcomtee_object_user_init()

by Robertus Diawan Chris

qcomtee_object_user_init() is a variadic function and when the function return because there's no dispatch callback in QCOMTEE_OBJECT_TYPE_CB case, there's no va_end to cleanup "ap" object initialized by va_start and that can cause undefined behavior. So make sure to use va_end before returning the error code when there's no dispatch callback. This is reported by Coverity Scan as "Missing varargs init or cleanup". Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Signed-off-by: Robertus Diawan Chris <robertusdchris(a)gmail.com> --- I don't have the device, so I am not sure how to test this change. Thank you. drivers/tee/qcomtee/core.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/tee/qcomtee/core.c b/drivers/tee/qcomtee/core.c index b1cb50e434f0..901a31e8201f 100644 --- a/drivers/tee/qcomtee/core.c +++ b/drivers/tee/qcomtee/core.c @@ -306,8 +306,10 @@ int qcomtee_object_user_init(struct qcomtee_object *object, break; case QCOMTEE_OBJECT_TYPE_CB: object->ops = ops; - if (!object->ops->dispatch) - return -EINVAL; + if (!object->ops->dispatch) { + ret = -EINVAL; + goto out; + } /* If failed, "no-name". */ object->name = kvasprintf_const(GFP_KERNEL, fmt, ap); @@ -320,6 +322,8 @@ int qcomtee_object_user_init(struct qcomtee_object *object, default: ret = -EINVAL; } + +out: va_end(ap); return ret; base-commit: 5d6919055dec134de3c40167a490f33c74c12581 -- 2.54.0

1 month

2
5
0 0

[PATCH v5 00/16] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#14: migrates all client drivers to generic PAS service. - Patch #15: drops legacy PAS SCM exported APIs. The patch-set is based on v7.1-rc1 tag and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 (already merged) [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v5: - Incorporated misc. comments from Mukesh. - Split up patch #11 into 2 to add an independent commit for passing proper PAS ID to set_remote_state API. - Picked up tags. Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (15): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs media: qcom: Pass proper PAS ID to set_remote_state API net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 19 + drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 291 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 476 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 25 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 8 +- drivers/remoteproc/Kconfig | 4 +- drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 28 files changed, 1117 insertions(+), 318 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

1 month

3
22
0 0

[PATCH] hwrng: tpm: Do not enable by default

by Jan Kiszka

From: Jan Kiszka <jan.kiszka(a)siemens.com> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write the current time epoch to its NV storage every 4 seconds if there are commands sent to it. The 60 seconds periodic update of the entropy pool that the hwrng kthread does triggers this, causing about 4 writes per requests. Makes 2 millions per year for a 24/7 device, and that is a lot for its backing NV storage. It is therefore better to make the user intentionally enable this, providing a chance to read the warning. [1] https://github.com/Microsoft/ms-tpm-20-ref Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com> --- drivers/char/tpm/Kconfig | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig index 8a8f692b6088..d64c929cacbe 100644 --- a/drivers/char/tpm/Kconfig +++ b/drivers/char/tpm/Kconfig @@ -45,13 +45,17 @@ config TCG_TPM2_HMAC config HW_RANDOM_TPM bool "TPM HW Random Number Generator support" depends on TCG_TPM && HW_RANDOM && !(TCG_TPM=y && HW_RANDOM=m) - default y help This setting exposes the TPM's Random Number Generator as a hwrng device. This allows the kernel to collect randomness from the TPM at boot, and provides the TPM randomines in /dev/hwrng. - If unsure, say Y. + WARNING: Specifically firmware-based TPMs, possibly also hardware + variants, can wear-out from the frequent requests issued by the + Hardware Random Number Generator Core when filling the kernel's + entropy pool. These requests are sent once every minute by default, + and the TPM may write the current time to its NV storage for each of + them. config TCG_TIS_CORE tristate -- 2.51.0

1 month, 1 week

4
11
0 0

[REPORT] tee: tee_ioctl_supp_recv() missing tee_shm_put() cleanup for memref params

by Qihang

Hi, I would like to report a likely shared-memory reference leak in drivers/tee/tee_core.c, in tee_ioctl_supp_recv(). The issue is that tee_ioctl_supp_recv() calls params_from_user(), which acquires references for MEMREF-type parameters via tee_shm_get_from_id(), but the cleanup path only frees the params array and does not drop the acquired shm references. Relevant code in tee_ioctl_supp_recv(): rc = params_from_user(ctx, params, num_params, uarg->params); if (rc) goto out; rc = ctx->teedev->desc->ops->supp_recv(ctx, &func, &num_params, params); if (rc) goto out; ... out: kfree(params); return rc; By contrast, other callers of params_from_user() in tee_core.c do release MEMREF references on cleanup, for example: - tee_ioctl_open_session() - tee_ioctl_invoke() - tee_ioctl_object_invoke() The helper comment in param_from_user_memref() also states that the caller is responsible for calling tee_shm_put() on all resolved pointers. Reachability / trigger paths: 1. qcomtee backend: qcomtee registers .supp_recv = qcomtee_supp_recv on a non-privileged tee device path. qcomtee_supp_recv() rejects any non-meta parameter after the first one: for (i = 1; i < *num_params; i++) if (params[i].attr) return -EINVAL; This allows a path where params_from_user() has already acquired a shm reference for a MEMREF parameter, then qcomtee_supp_recv() returns an error, and tee_ioctl_supp_recv() exits without tee_shm_put(). 2. Partial failure before backend callback: if params_from_user() successfully resolves an earlier MEMREF parameter and then fails on a later parameter, tee_ioctl_supp_recv() still goes to the same cleanup path without dropping already acquired shm refs. This means the issue is not just a backend-specific quirk: the core ioctl cleanup path itself is missing tee_shm_put() handling. Impact: - leaked shared-memory references - shared-memory objects may remain pinned and never reach final release - repeated triggering can cause resource exhaustion / DoS This does not appear to be a UAF, since refcount_t saturation prevents wraparound. The impact looks limited to resource leakage and availability. If useful, I can also prepare a patch. Thanks, Qihang

1 month, 1 week

3
12
0 0

KLMBG4GEUF

by İsa Coşkun

Hello, I am working on embedded automotive systems repair and investigating behavior of Samsung eMMC (KLMBG4GEUF) in systems that appear to use OP-TEE for secure storage. Real scenario: - Two identical devices (same hardware) - One working, one not booting - Full eMMC dump taken from working device: - USER - BOOT1 / BOOT2 - EXT_CSD - RPMB (reported readable, but content appears empty or not usable) Tests: - Writing full dump to another device → no boot - Swapping eMMC between boards → both fail - Writing only USER → no change From observations: - RPMB appears non-clonable - Secure storage likely bound to hardware - Boot seems dependent on this binding Questions: 1. In OP-TEE, is RPMB always tied to a hardware unique key (HUK)? 2. Is it expected that RPMB content cannot be reused across identical devices? 3. Does OP-TEE enforce secure storage binding in a way that prevents cloning? 4. In case of damaged eMMC, is there any supported way to reinitialize or recover secure storage? I am not trying to bypass security, but to understand the architectural limitation in real repair scenarios. Any clarification would be highly appreciated. Best regards

1 month, 2 weeks

2
1
0 0

[PATCH v4 00/15] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Note that kernel PAS service support while running in EL2 is at parity among OP-TEE vs QTEE. Especially the media (venus/iris) support depends on proper IOMMU support being worked out on the PAS client end. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#13: migrates all client drivers to generic PAS service. - Patch #14: drops legacy PAS SCM exported APIs. The patch-set is based on v7.1-rc1 tag and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v4: - Incorporate misc. comments on patch #4. - Picked up an ack for patch #10. - Clarify in cover letter about state of media support. Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (14): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 19 + drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 288 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 479 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 25 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 8 +- drivers/remoteproc/Kconfig | 1 + drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 28 files changed, 1115 insertions(+), 317 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

1 month, 2 weeks

4
44
0 0

[PATCH v11 00/11] Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE)

by Amirreza Zarrabi

This patch series introduces a Trusted Execution Environment (TEE) driver for Qualcomm TEE (QTEE). QTEE enables Trusted Applications (TAs) and services to run securely. It uses an object-based interface, where each service is an object with sets of operations. Clients can invoke these operations on objects, which can generate results, including other objects. For example, an object can load a TA and return another object that represents the loaded TA, allowing access to its services. Kernel and userspace services are also available to QTEE through a similar approach. QTEE makes callback requests that are converted into object invocations. These objects can represent services within the kernel or userspace process. Note: This patch series focuses on QTEE objects and userspace services. Linux already provides a TEE subsystem, which is described in [1]. The tee subsystem provides a generic ioctl interface, TEE_IOC_INVOKE, which can be used by userspace to talk to a TEE backend driver. We extend the Linux TEE subsystem to understand object parameters and an ioctl call so client can invoke objects in QTEE: - TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF_* - TEE_IOC_OBJECT_INVOKE The existing ioctl calls TEE_IOC_SUPPL_RECV and TEE_IOC_SUPPL_SEND are used for invoking services in the userspace process by QTEE. The TEE backend driver uses the QTEE Transport Message to communicate with QTEE. Interactions through the object INVOKE interface are translated into QTEE messages. Likewise, object invocations from QTEE for userspace objects are converted into SEND/RECV ioctl calls to supplicants. The details of QTEE Transport Message to communicate with QTEE is available in [PATCH 12/12] Documentation: tee: Add Qualcomm TEE driver. You can run basic tests with following steps: git clone https://github.com/quic/quic-teec.git cd quic-teec mkdir build cmake .. -DCMAKE_TOOLCHAIN_FILE=CMakeToolchain.txt -DBUILD_UNITTEST=ON https://github.com/quic/quic-teec/blob/main/README.md lists dependencies needed to build the above. More comprehensive tests are availabe at https://github.com/qualcomm/minkipc. root@qcom-armv8a:~# qtee_supplicant & root@qcom-armv8a:~# qtee_supplicant: process entry PPID = 378 Total listener services to start = 4 Opening CRequestTABuffer_open Path /data/ register_service ::Opening CRegisterTABufCBO_UID Calling TAbufCBO Register QTEE_SUPPLICANT RUNNING root@qcom-armv8a:~# smcinvoke_client -c /data 1 Run callback obj test... Load /data/tzecotestapp.mbn, size 52192, buf 0x1e44ba0. System Time: 2024-02-27 17:26:31 PASSED - Callback tests with Buffer inputs. PASSED - Callback tests with Remote and Callback object inputs. PASSED - Callback tests with Memory Object inputs. TEST PASSED! root@qcom-armv8a:~# root@qcom-armv8a:~# smcinvoke_client -m /data 1 Run memory obj test... Load /data/tzecotestapp.mbn, size 52192, buf 0x26cafba0. System Time: 2024-02-27 17:26:39 PASSED - Single Memory Object access Test. PASSED - Two Memory Object access Test. TEST PASSED! This series has been tested for QTEE object invocations, including loading a TA, requesting services from the TA, memory sharing, and handling callback requests to a supplicant. Tested platforms: sm8650-mtp, sm8550-qrd, sm8650-qrd, sm8650-hdk [1] https://www.kernel.org/doc/Documentation/tee.txt Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> Changes in v11: - Rebased on next. - Link to v10: https://lore.kernel.org/r/20250909-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v10: - Remove all loggings in qcom_scm_qtee_init(). - Reorder patches. - Link to v9: https://lore.kernel.org/r/20250901-qcom-tee-using-tee-ss-without-mem-obj-v9… Changes in v9: - Remove unnecessary logging in qcom_scm_probe(). - Replace the platform_device_alloc()/add() sequence with platform_device_register_data(). - Fixed sparse warning. - Fixed documentation typo. - Link to v8: https://lore.kernel.org/r/20250820-qcom-tee-using-tee-ss-without-mem-obj-v8… Changes in v8: - Check if arguments to qcom_scm_qtee_invoke_smc() and qcom_scm_qtee_callback_response() are NULL. - Add CPU_BIG_ENDIAN as a dependency to Kconfig. - Fixed kernel bot errors. - Link to v7: https://lore.kernel.org/r/20250812-qcom-tee-using-tee-ss-without-mem-obj-v7… Changes in v7: - Updated copyrights. - Updated Acked-by: tags. - Fixed kernel bot errors. - Link to v6: https://lore.kernel.org/r/20250713-qcom-tee-using-tee-ss-without-mem-obj-v6… Changes in v6: - Relocate QTEE version into the driver's main service structure. - Simplfies qcomtee_objref_to_arg() and qcomtee_objref_from_arg(). - Enhanced the return logic of qcomtee_object_do_invoke_internal(). - Improve comments and remove redundant checks. - Improve helpers in qcomtee_msh.h to use GENMASK() and FIELD_GET(). - updated Tested-by:, Acked-by:, and Reviewed-by: tags - Link to v5: https://lore.kernel.org/r/20250526-qcom-tee-using-tee-ss-without-mem-obj-v5… Changes in v5: - Remove references to kernel services and public APIs. - Support auto detection for failing devices (e.g., RB1, RB4). - Add helpers for obtaining client environment and service objects. - Query the QTEE version and print it. - Move remaining static variables, including the object table, to struct qcomtee. - Update TEE_MAX_ARG_SIZE to 4096. - Add a dependancy to QCOM_TZMEM_MODE_SHMBRIDGE in Kconfig - Reorganize code by removing release.c and qcom_scm.c. - Add more error messages and improve comments. - updated Tested-by:, Acked-by:, and Reviewed-by: tags - Link to v4: https://lore.kernel.org/r/20250428-qcom-tee-using-tee-ss-without-mem-obj-v4… Changes in v4: - Move teedev_ctx_get/put and tee_device_get/put to tee_core.h. - Rename object to id in struct tee_ioctl_object_invoke_arg. - Replace spinlock with mutex for qtee_objects_idr. - Move qcomtee_object_get to qcomtee_user/memobj_param_to_object. - More code cleanup following the comments. - Cleanup documentations. - Update MAINTAINERS file. - Link to v3: https://lore.kernel.org/r/20250327-qcom-tee-using-tee-ss-without-mem-obj-v3… Changes in v3: - Export shm_bridge create/delete APIs. - Enable support for QTEE memory objects. - Update the memory management code to use the TEE subsystem for all allocations using the pool. - Move all driver states into the driver's main service struct. - Add more documentations. - Link to v2: https://lore.kernel.org/r/20250202-qcom-tee-using-tee-ss-without-mem-obj-v2… Changes in v2: - Clean up commit messages and comments. - Use better names such as ubuf instead of membuf or QCOMTEE prefix instead of QCOM_TEE, or names that are more consistent with other TEE-backend drivers such as qcomtee_context_data instead of qcom_tee_context. - Drop the DTS patch and instantiate the device from the scm driver. - Use a single structure for all driver's internal states. - Drop srcu primitives and use the existing mutex for synchronization between the supplicant and QTEE. - Directly use tee_context to track the lifetime of qcomtee_context_data. - Add close_context() to be called when the user closes the tee_context. - Link to v1: https://lore.kernel.org/r/20241202-qcom-tee-using-tee-ss-without-mem-obj-v1… Changes in v1: - It is a complete rewrite to utilize the TEE subsystem. - Link to RFC: https://lore.kernel.org/all/20240702-qcom-tee-object-and-ioctls-v1-0-633c3d… --- Amirreza Zarrabi (11): firmware: qcom: tzmem: export shm_bridge create/delete firmware: qcom: scm: add support for object invocation tee: allow a driver to allocate a tee_device without a pool tee: add close_context to TEE driver operation tee: add TEE_IOCTL_PARAM_ATTR_TYPE_UBUF tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF tee: increase TEE_MAX_ARG_SIZE to 4096 tee: add Qualcomm TEE driver tee: qcom: add primordial object tee: qcom: enable TEE_IOC_SHM_ALLOC ioctl Documentation: tee: Add Qualcomm TEE driver Documentation/tee/index.rst | 1 + Documentation/tee/qtee.rst | 96 ++++ MAINTAINERS | 7 + drivers/firmware/qcom/qcom_scm.c | 119 ++++ drivers/firmware/qcom/qcom_scm.h | 7 + drivers/firmware/qcom/qcom_tzmem.c | 63 ++- drivers/tee/Kconfig | 1 + drivers/tee/Makefile | 1 + drivers/tee/qcomtee/Kconfig | 12 + drivers/tee/qcomtee/Makefile | 9 + drivers/tee/qcomtee/async.c | 182 ++++++ drivers/tee/qcomtee/call.c | 820 +++++++++++++++++++++++++++ drivers/tee/qcomtee/core.c | 915 +++++++++++++++++++++++++++++++ drivers/tee/qcomtee/mem_obj.c | 169 ++++++ drivers/tee/qcomtee/primordial_obj.c | 113 ++++ drivers/tee/qcomtee/qcomtee.h | 185 +++++++ drivers/tee/qcomtee/qcomtee_msg.h | 304 ++++++++++ drivers/tee/qcomtee/qcomtee_object.h | 316 +++++++++++ drivers/tee/qcomtee/shm.c | 150 +++++ drivers/tee/qcomtee/user_obj.c | 692 +++++++++++++++++++++++ drivers/tee/tee_core.c | 127 ++++- drivers/tee/tee_private.h | 6 - include/linux/firmware/qcom/qcom_scm.h | 6 + include/linux/firmware/qcom/qcom_tzmem.h | 15 + include/linux/tee_core.h | 54 +- include/linux/tee_drv.h | 12 + include/uapi/linux/tee.h | 56 +- 27 files changed, 4410 insertions(+), 28 deletions(-) --- base-commit: 8b8aefa5a5c7d4a65883e5653cf12f94c0b68dbf change-id: 20241202-qcom-tee-using-tee-ss-without-mem-obj-362c66340527 Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

1 month, 2 weeks

3
15
0 0

KLMBG4GEUF

by İsa Coşkun

Hello, I am working on embedded automotive systems repair and investigating behavior of Samsung eMMC (KLMBG4GEUF) in systems that appear to use OP-TEE for secure storage. Real scenario: - Two identical devices (same hardware) - One working, one not booting - Full eMMC dump taken from working device: - USER - BOOT1 / BOOT2 - EXT_CSD - RPMB (reported readable, but content appears empty or not usable) Tests: - Writing full dump to another device → no boot - Swapping eMMC between boards → both fail - Writing only USER → no change From observations: - RPMB appears non-clonable - Secure storage likely bound to hardware - Boot seems dependent on this binding Questions: 1. In OP-TEE, is RPMB always tied to a hardware unique key (HUK)? 2. Is it expected that RPMB content cannot be reused across identical devices? 3. Does OP-TEE enforce secure storage binding in a way that prevents cloning? 4. In case of damaged eMMC, is there any supported way to reinitialize or recover secure storage? I am not trying to bypass security, but to understand the architectural limitation in real repair scenarios. Any clarification would be highly appreciated. Best regards,

1 month, 3 weeks

1
0
0 0

[PATCH] tee: optee: Allow MT_NORMAL_TAGGED shared memory

by Hirokazu Honda

From: Hirokazu Honda <hiroh(a)chromium.org> On ARM64, shared memory can have MT_NORMAL_TAGGED attribute when using the Memory Tagging Extension (MTE). The OP-TEE driver needs to recognize this as normal memory to allow sharing such buffers with the Secure World. Signed-off-by: Hirokazu Honda <hiroh(a)chromium.org> --- drivers/tee/optee/call.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c index 9effe88049e9..e046aff61828 100644 --- a/drivers/tee/optee/call.c +++ b/drivers/tee/optee/call.c @@ -602,7 +602,8 @@ static bool is_normal_memory(pgprot_t p) return (((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEALLOC) || ((pgprot_val(p) & L_PTE_MT_MASK) == L_PTE_MT_WRITEBACK)); #elif defined(CONFIG_ARM64) - return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); + return ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL)) || + ((pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL_TAGGED)); #else #error "Unsupported architecture" #endif -- 2.54.0.rc1.513.gad8abe7a5a-goog

1 month, 3 weeks

3
3
0 0

[PATCH 1/1] tee: amdtee: store buffer ID in tee_shm->sec_world_id

by Rijo Thomas

Drop struct amdtee_shm_data and the per-context shm_list. In handle_map_shmem() save the returned buf_id in shm->sec_world_id instead of allocating a list node. Use shm->sec_world_id (with get_buffer_id() removed) in amdtee_unmap_shmem() and in call.c when building memref params. Remove shm_list and shm_mutex from amdtee_context_data. Aligns amdtee with other TEE drivers (optee, tstee, qcomtee) that use tee_shm->sec_world_id for the secure-world handle. Signed-off-by: Rijo Thomas <Rijo-john.Thomas(a)amd.com> --- drivers/tee/amdtee/amdtee_private.h | 16 --------- drivers/tee/amdtee/call.c | 2 +- drivers/tee/amdtee/core.c | 52 +++-------------------------- 3 files changed, 5 insertions(+), 65 deletions(-) diff --git a/drivers/tee/amdtee/amdtee_private.h b/drivers/tee/amdtee/amdtee_private.h index d87050033894..2c5ba02258b8 100644 --- a/drivers/tee/amdtee/amdtee_private.h +++ b/drivers/tee/amdtee/amdtee_private.h @@ -65,13 +65,9 @@ struct amdtee_session { /** * struct amdtee_context_data - AMD-TEE driver context data * @sess_list: Keeps track of sessions opened in current TEE context - * @shm_list: Keeps track of buffers allocated and mapped in current TEE - * context */ struct amdtee_context_data { struct list_head sess_list; - struct list_head shm_list; - struct mutex shm_mutex; /* synchronizes access to @shm_list */ }; struct amdtee_driver_data { @@ -83,17 +79,6 @@ struct shmem_desc { u64 size; }; -/** - * struct amdtee_shm_data - Shared memory data - * @kaddr: Kernel virtual address of shared memory - * @buf_id: Buffer id of memory mapped by TEE_CMD_ID_MAP_SHARED_MEM - */ -struct amdtee_shm_data { - struct list_head shm_node; - void *kaddr; - u32 buf_id; -}; - /** * struct amdtee_ta_data - Keeps track of all TAs loaded in AMD Secure * Processor @@ -168,5 +153,4 @@ int handle_invoke_cmd(struct tee_ioctl_invoke_arg *arg, u32 sinfo, struct tee_shm_pool *amdtee_config_shm(void); -u32 get_buffer_id(struct tee_shm *shm); #endif /*AMDTEE_PRIVATE_H*/ diff --git a/drivers/tee/amdtee/call.c b/drivers/tee/amdtee/call.c index 441b2ceaafc3..23ccd0f037a7 100644 --- a/drivers/tee/amdtee/call.c +++ b/drivers/tee/amdtee/call.c @@ -45,7 +45,7 @@ static int tee_params_to_amd_params(struct tee_param *tee, u32 count, /* It is assumed that all values are within 2^32-1 */ if (type > TEE_OP_PARAM_TYPE_VALUE_INOUT) { - u32 buf_id = get_buffer_id(tee[i].u.memref.shm); + u32 buf_id = (u32)tee[i].u.memref.shm->sec_world_id; amd->params[i].mref.buf_id = buf_id; amd->params[i].mref.offset = tee[i].u.memref.shm_offs; diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c index a1347d04b3ac..0e56f4cf2697 100644 --- a/drivers/tee/amdtee/core.c +++ b/drivers/tee/amdtee/core.c @@ -43,8 +43,6 @@ static int amdtee_open(struct tee_context *ctx) return -ENOMEM; INIT_LIST_HEAD(&ctxdata->sess_list); - INIT_LIST_HEAD(&ctxdata->shm_list); - mutex_init(&ctxdata->shm_mutex); ctx->data = ctxdata; return 0; @@ -87,7 +85,6 @@ static void amdtee_release(struct tee_context *ctx) list_del(&sess->list_node); release_session(sess); } - mutex_destroy(&ctxdata->shm_mutex); kfree(ctxdata); ctx->data = NULL; @@ -152,23 +149,6 @@ static struct amdtee_session *find_session(struct amdtee_context_data *ctxdata, return NULL; } -u32 get_buffer_id(struct tee_shm *shm) -{ - struct amdtee_context_data *ctxdata = shm->ctx->data; - struct amdtee_shm_data *shmdata; - u32 buf_id = 0; - - mutex_lock(&ctxdata->shm_mutex); - list_for_each_entry(shmdata, &ctxdata->shm_list, shm_node) - if (shmdata->kaddr == shm->kaddr) { - buf_id = shmdata->buf_id; - break; - } - mutex_unlock(&ctxdata->shm_mutex); - - return buf_id; -} - static DEFINE_MUTEX(drv_mutex); static int copy_ta_binary(struct tee_context *ctx, void *ptr, void **ta, size_t *ta_size) @@ -342,8 +322,6 @@ int amdtee_close_session(struct tee_context *ctx, u32 session) int amdtee_map_shmem(struct tee_shm *shm) { - struct amdtee_context_data *ctxdata; - struct amdtee_shm_data *shmnode; struct shmem_desc shmem; int rc, count; u32 buf_id; @@ -351,10 +329,6 @@ int amdtee_map_shmem(struct tee_shm *shm) if (!shm) return -EINVAL; - shmnode = kmalloc_obj(*shmnode); - if (!shmnode) - return -ENOMEM; - count = 1; shmem.kaddr = shm->kaddr; shmem.size = shm->size; @@ -366,44 +340,26 @@ int amdtee_map_shmem(struct tee_shm *shm) rc = handle_map_shmem(count, &shmem, &buf_id); if (rc) { pr_err("map_shmem failed: ret = %d\n", rc); - kfree(shmnode); return rc; } - shmnode->kaddr = shm->kaddr; - shmnode->buf_id = buf_id; - ctxdata = shm->ctx->data; - mutex_lock(&ctxdata->shm_mutex); - list_add(&shmnode->shm_node, &ctxdata->shm_list); - mutex_unlock(&ctxdata->shm_mutex); + shm->sec_world_id = buf_id; - pr_debug("buf_id :[%x] kaddr[%p]\n", shmnode->buf_id, shmnode->kaddr); + pr_debug("buf_id :[%x] kaddr[%p]\n", buf_id, shm->kaddr); return 0; } void amdtee_unmap_shmem(struct tee_shm *shm) { - struct amdtee_context_data *ctxdata; - struct amdtee_shm_data *shmnode; u32 buf_id; if (!shm) return; - buf_id = get_buffer_id(shm); - /* Unmap the shared memory from TEE */ + buf_id = (u32)shm->sec_world_id; handle_unmap_shmem(buf_id); - - ctxdata = shm->ctx->data; - mutex_lock(&ctxdata->shm_mutex); - list_for_each_entry(shmnode, &ctxdata->shm_list, shm_node) - if (buf_id == shmnode->buf_id) { - list_del(&shmnode->shm_node); - kfree(shmnode); - break; - } - mutex_unlock(&ctxdata->shm_mutex); + shm->sec_world_id = 0; } int amdtee_invoke_func(struct tee_context *ctx, -- 2.43.0

1 month, 3 weeks

3
2
0 0

[PATCH] tee: optee: fix kernel-doc warnings

by Rodrigo Zaiden

Fix kernel-doc issues in optee_private.h and optee_msg.h: - Add missing documentation for struct members: optee_msg_param_value, optee_msg_param, optee_msg_arg, optee, and optee_ffa; - Ensure member descriptions follow the order of declaration; - Use consistent formatting (lowercase descriptions and ':' after member names); - Adjust indentation for better alignment; This resolves kernel-doc warnings such as missing member descriptions and incorrect prototype documentation. No functional changes. Signed-off-by: Rodrigo Zaiden <rodrigoffzz(a)gmail.com> --- drivers/tee/optee/optee_msg.h | 50 +++++++------ drivers/tee/optee/optee_private.h | 120 ++++++++++++++++-------------- 2 files changed, 92 insertions(+), 78 deletions(-) diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 838e1d4a22f0..7d9b12e71c03 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -103,9 +103,9 @@ /** * struct optee_msg_param_tmem - temporary memory reference parameter - * @buf_ptr: Address of the buffer - * @size: Size of the buffer - * @shm_ref: Temporary shared memory reference, pointer to a struct tee_shm + * @buf_ptr: address of the buffer + * @size: size of the buffer + * @shm_ref: temporary shared memory reference, pointer to a struct tee_shm * * Secure and normal world communicates pointers as physical address * instead of the virtual address. This is because secure and normal world @@ -122,9 +122,9 @@ struct optee_msg_param_tmem { /** * struct optee_msg_param_rmem - registered memory reference parameter - * @offs: Offset into shared memory reference - * @size: Size of the buffer - * @shm_ref: Shared memory reference, pointer to a struct tee_shm + * @offs: offset into shared memory reference + * @size: size of the buffer + * @shm_ref: shared memory reference, pointer to a struct tee_shm */ struct optee_msg_param_rmem { u64 offs; @@ -134,12 +134,12 @@ struct optee_msg_param_rmem { /** * struct optee_msg_param_fmem - FF-A memory reference parameter - * @offs_lower: Lower bits of offset into shared memory reference - * @offs_upper: Upper bits of offset into shared memory reference - * @internal_offs: Internal offset into the first page of shared memory - * reference - * @size: Size of the buffer - * @global_id: Global identifier of the shared memory + * @offs_low: lower bits of offset into shared memory reference + * @offs_high: higher bits of offset into shared memory reference + * @internal_offs: internal offset into the first page of shared memory + * reference + * @size: size of the buffer + * @global_id: global identifier of the shared memory */ struct optee_msg_param_fmem { u32 offs_low; @@ -151,6 +151,9 @@ struct optee_msg_param_fmem { /** * struct optee_msg_param_value - opaque value parameter + * @a: first opaque value + * @b: second opaque value + * @c: third opaque value * * Value parameters are passed unchecked between normal and secure world. */ @@ -168,6 +171,7 @@ struct optee_msg_param_value { * @fmem: parameter by FF-A registered memory reference * @value: parameter by opaque value * @octets: parameter by octet string + * @u: union holding OP-TEE msg parameter * * @attr & OPTEE_MSG_ATTR_TYPE_MASK indicates if tmem, rmem or value is used in * the union. OPTEE_MSG_ATTR_TYPE_VALUE_* indicates value or octets, @@ -189,16 +193,18 @@ struct optee_msg_param { /** * struct optee_msg_arg - call argument - * @cmd: Command, one of OPTEE_MSG_CMD_* or OPTEE_MSG_RPC_CMD_* - * @func: Trusted Application function, specific to the Trusted Application, - * used if cmd == OPTEE_MSG_CMD_INVOKE_COMMAND - * @session: In parameter for all OPTEE_MSG_CMD_* except - * OPTEE_MSG_CMD_OPEN_SESSION where it's an output parameter instead - * @cancel_id: Cancellation id, a unique value to identify this request - * @ret: return value - * @ret_origin: origin of the return value - * @num_params: number of parameters supplied to the OS Command - * @params: the parameters supplied to the OS Command + * @cmd: command, one of OPTEE_MSG_CMD_* or OPTEE_MSG_RPC_CMD_* + * @func: Trusted Application function, specific to the Trusted + * Application, used if cmd == OPTEE_MSG_CMD_INVOKE_COMMAND + * @session: in parameter for all OPTEE_MSG_CMD_* except + * OPTEE_MSG_CMD_OPEN_SESSION where it's an output parameter + * instead + * @cancel_id: cancellation id, a unique value to identify this request + * @pad: padding for alignment + * @ret: return value + * @ret_origin: origin of the return value + * @num_params: number of parameters supplied to the OS Command + * @params: the parameters supplied to the OS Command * * All normal calls to Trusted OS uses this struct. If cmd requires further * information than what these fields hold it can be passed as a parameter diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h index acd3051c4879..aefe1e6f5689 100644 --- a/drivers/tee/optee/optee_private.h +++ b/drivers/tee/optee/optee_private.h @@ -47,11 +47,11 @@ typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, struct arm_smccc_res *); -/* +/** * struct optee_call_waiter - TEE entry may need to wait for a free TEE thread - * @list_node Reference in waiters list - * @c Waiting completion reference - * @sys_thread True if waiter belongs to a system thread + * @list_node: reference in waiters list + * @c: waiting completion reference + * @sys_thread: true if waiter belongs to a system thread */ struct optee_call_waiter { struct list_head list_node; @@ -59,13 +59,13 @@ struct optee_call_waiter { bool sys_thread; }; -/* +/** * struct optee_call_queue - OP-TEE call queue management - * @mutex Serializes access to this struct - * @waiters List of threads waiting to enter OP-TEE - * @total_thread_count Overall number of thread context in OP-TEE or 0 - * @free_thread_count Number of threads context free in OP-TEE - * @sys_thread_req_count Number of registered system thread sessions + * @mutex: serializes access to this struct + * @waiters: list of threads waiting to enter OP-TEE + * @total_thread_count: overall number of thread context in OP-TEE or 0 + * @free_thread_count: number of threads context free in OP-TEE + * @sys_thread_req_count: number of registered system thread sessions */ struct optee_call_queue { /* Serializes access to this struct */ @@ -96,17 +96,17 @@ struct optee_shm_arg_cache { /** * struct optee_supp - supplicant synchronization struct - * @ctx the context of current connected supplicant. - * if !NULL the supplicant device is available for use, - * else busy - * @mutex: held while accessing content of this struct - * @req_id: current request id if supplicant is doing synchronous - * communication, else -1 - * @reqs: queued request not yet retrieved by supplicant - * @idr: IDR holding all requests currently being processed - * by supplicant - * @reqs_c: completion used by supplicant when waiting for a - * request to be queued. + * @mutex: held while accessing content of this struct + * @ctx: the context of current connected supplicant. + * if !NULL the supplicant device is available for use, + * else busy + * @req_id: current request id if supplicant is doing synchronous + * communication, else -1 + * @reqs: queued request not yet retrieved by supplicant + * @idr: IDR holding all requests currently being processed + * by supplicant + * @reqs_c: completion used by supplicant when waiting for a + * request to be queued. */ struct optee_supp { /* Serializes access to this struct */ @@ -119,25 +119,25 @@ struct optee_supp { struct completion reqs_c; }; -/* +/** * struct optee_pcpu - per cpu notif private struct passed to work functions - * @optee optee device reference + * @optee: optee device reference */ struct optee_pcpu { struct optee *optee; }; -/* +/** * struct optee_smc - optee smc communication struct - * @invoke_fn handler function to invoke secure monitor - * @memremaped_shm virtual address of memory in shared memory pool + * @invoke_fn: handler function to invoke secure monitor + * @memremaped_shm: virtual address of memory in shared memory pool * @sec_caps: secure world capabilities defined by * OPTEE_SMC_SEC_CAP_* in optee_smc.h - * @notif_irq interrupt used as async notification by OP-TEE or 0 - * @optee_pcpu per_cpu optee instance for per cpu work or NULL - * @notif_pcpu_wq workqueue for per cpu asynchronous notification or NULL - * @notif_pcpu_work work for per cpu asynchronous notification - * @notif_cpuhp_state CPU hotplug state assigned for pcpu interrupt management + * @notif_irq: interrupt used as async notification by OP-TEE or 0 + * @optee_pcpu: per_cpu optee instance for per cpu work or NULL + * @notif_pcpu_wq: workqueue for per cpu asynchronous notification or NULL + * @notif_pcpu_work: work for per cpu asynchronous notification + * @notif_cpuhp_state: CPU hotplug state assigned for pcpu interrupt management */ struct optee_smc { optee_invoke_fn *invoke_fn; @@ -151,13 +151,15 @@ struct optee_smc { }; /** - * struct optee_ffa_data - FFA communication struct - * @ffa_dev FFA device, contains the destination id, the id of + * struct optee_ffa - FFA communication struct + * @ffa_dev: FFA device, contains the destination id, the id of * OP-TEE in secure world - * @bottom_half_value Notification ID used for bottom half signalling or + * @bottom_half_value: notification ID used for bottom half signalling or * U32_MAX if unused - * @mutex Serializes access to @global_ids - * @global_ids FF-A shared memory global handle translation + * @mutex: serializes access to @global_ids + * @global_ids: FF-A shared memory global handle translation + * @notif_wq: workqueue for FF-A asynchronous notification + * @notif_work: work for FF-A asynchronous notification */ struct optee_ffa { struct ffa_device *ffa_dev; @@ -222,26 +224,32 @@ struct optee_ops { /** * struct optee - main service struct - * @supp_teedev: supplicant device - * @teedev: client device - * @ops: internal callbacks for different ways to reach secure - * world - * @ctx: driver internal TEE context - * @smc: specific to SMC ABI - * @ffa: specific to FF-A ABI - * @call_queue: queue of threads waiting to call @invoke_fn - * @notif: notification synchronization struct - * @supp: supplicant synchronization struct for RPC to supplicant - * @pool: shared memory pool - * @mutex: mutex protecting @rpmb_dev - * @rpmb_dev: current RPMB device or NULL - * @rpmb_scan_bus_done flag if device registation of RPMB dependent devices - * was already done - * @rpmb_scan_bus_work workq to for an RPMB device and to scan optee bus - * and register RPMB dependent optee drivers - * @rpc_param_count: If > 0 number of RPC parameters to make room for - * @scan_bus_done flag if device registation was already done. - * @scan_bus_work workq to scan optee bus and register optee drivers + * @supp_teedev: supplicant device + * @teedev: client device + * @ops: internal callbacks for different ways to reach + * secure world + * @ctx: driver internal TEE context + * @smc: specific to SMC ABI + * @ffa: specific to FF-A ABI + * @shm_arg_cache: shared memory cache argument + * @call_queue: queue of threads waiting to call @invoke_fn + * @notif: notification synchronization struct + * @supp: supplicant synchronization struct for RPC to + * supplicant + * @pool: shared memory pool + * @rpmb_dev_mutex: mutex protecting @rpmb_dev + * @rpmb_dev: current RPMB device or NULL + * @rpmb_intf: RPMB notifier block + * @rpc_param_count: if > 0 number of RPC parameters to make room for + * @scan_bus_done: flag if device registation was already done + * @rpmb_scan_bus_done: flag if device registation of RPMB dependent + * devices was already done + * @in_kernel_rpmb_routing: flag if OP-TEE supports in-kernel RPMB routing + * @scan_bus_work: workq to scan optee bus and register optee + * drivers + * @rpmb_scan_bus_work: workq to for an RPMB device and to scan optee + * bus and register RPMB dependent optee drivers + * @revision: OP-TEE OS revision */ struct optee { struct tee_device *supp_teedev; -- 2.43.0

1 month, 3 weeks

3
2
0 0

[PATCH] tee: shm: fix shm leak in register_shm_helper()

by Georgiy Osokin

register_shm_helper() allocates shm before calling iov_iter_npages(). If iov_iter_npages() returns 0, the function jumps to err_ctx_put and leaks shm. This can be triggered by TEE_IOC_SHM_REGISTER with struct tee_ioctl_shm_register_data where length is 0. Jump to err_free_shm instead. Fixes: 7bdee4157591 ("tee: Use iov_iter to better support shared buffer registration") 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 e9ea9f80cfd9..6742b3579c86 100644 --- a/drivers/tee/tee_shm.c +++ b/drivers/tee/tee_shm.c @@ -435,7 +435,7 @@ register_shm_helper(struct tee_context *ctx, struct iov_iter *iter, u32 flags, num_pages = iov_iter_npages(iter, INT_MAX); if (!num_pages) { ret = ERR_PTR(-ENOMEM); - goto err_ctx_put; + goto err_free_shm; } shm->pages = kzalloc_objs(*shm->pages, num_pages); -- 2.50.1

1 month, 3 weeks

3
2
0 0

[PATCH] tee: fix tee_ioctl_object_invoke_arg padding

by Arnd Bergmann

From: Arnd Bergmann <arnd(a)arndb.de> The tee_ioctl_object_invoke_arg structure has padding on some architectures but not on x86-32 and a few others: include/linux/tee.h:474:32: error: padding struct to align 'params' [-Werror=padded] I expect that all current users of this are on architectures that do have implicit padding here (arm64, arm, x86, riscv), so make the padding explicit in order to avoid surprises if this later gets used elsewhere. Fixes: d5b8b0fa1775 ("tee: add TEE_IOCTL_PARAM_ATTR_TYPE_OBJREF") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- The new interface showed up in 6.18, but I only came across this after that was released. Changing it now is technically an ABI change on architectures with unusual padding rules, so please consider carefully whether we want to do it this way or not. Working around the ABI differences without an ABI change is possible, but adds a lot of complexity for compat handling. --- include/uapi/linux/tee.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h index cab5cadca8ef..5203977ed35d 100644 --- a/include/uapi/linux/tee.h +++ b/include/uapi/linux/tee.h @@ -470,6 +470,7 @@ struct tee_ioctl_object_invoke_arg { __u32 op; __u32 ret; __u32 num_params; + __u32 :32; /* num_params tells the actual number of element in params */ struct tee_ioctl_param params[]; }; -- 2.39.5

1 month, 3 weeks

6
12
0 0

[GIT PULL] OP-TEE fix for 7.0

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch fixing a use-after-free race in the OP-TEE driver where a client exiting prematurely could free a request still being processed by the supplicant. Thanks, Jens The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f: Linux 7.0-rc1 (2026-02-22 13:18:59 -0800) are available in the Git repository at: gitolite.kernel.org:pub/scm/linux/kernel/git/jenswi/linux-tee tags/optee-fix-for-v7.0 for you to fetch changes up to 387a926ee166814611acecb960207fe2f3c4fd3e: tee: optee: prevent use-after-free when the client exits before the supplicant (2026-03-02 14:36:50 +0100) ---------------------------------------------------------------- OP-TEE fix for v7.0 Fix a use-after-free race between client and supplicant by serializing request access with the supplicant mutex. ---------------------------------------------------------------- Amirreza Zarrabi (1): tee: optee: prevent use-after-free when the client exits before the supplicant drivers/tee/optee/supp.c | 107 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 74 insertions(+), 33 deletions(-)

1 month, 3 weeks

1
1
0 0

[PATCH v3 00/15] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#13: migrates all client drivers to generic PAS service. - Patch #14: drops legacy PAS SCM exported APIs. The patch-set is based on v7.0-rc5 tag and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v3: - Incorporated some style and misc. comments for patch #2, #3 and #4. - Add QCOM_PAS Kconfig dependency for various subsystems. - Switch from pseudo TA to proper TA invoke commands. Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (14): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS generic service drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 19 + drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 288 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 50 ++ drivers/firmware/qcom/qcom_pas_tee.c | 478 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 302 ++++------- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- drivers/media/platform/qcom/iris/Kconfig | 25 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/Kconfig | 1 + drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/Kconfig | 2 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/Kconfig | 2 +- drivers/net/wireless/ath/ath12k/ahb.c | 8 +- drivers/remoteproc/Kconfig | 1 + drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 43 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 28 files changed, 1114 insertions(+), 317 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

2 months

6
29
0 0

OP-TEE 4.10.0 has been released

by Jens Wiklander

Hi, I'm pleased to announce that OP-TEE version 4.10.0 is now available. The list of changes can be found in the changelog [1]. A big thank you to everyone who participated with contributions and helping out with testing the release [2]. [1] https://github.com/OP-TEE/optee_os/blob/4.10.0/CHANGELOG.md [2] https://github.com/OP-TEE/optee_os/commit/753afbbee1682f5d16fd30e87b31058a4… Regards, Jens

2 months, 1 week

1
0
0 0

[PATCH v22 0/7] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Main updates from version V21[1]: -------------------------------- This version removes the st,stm32mp1-m4-tee compatibility string, which no longer seems to be accepted by the Devicetree maintainers. As a consequence, the stm32-rproc-tee driver, introduced to simplify the code, is removed. The STM32 integration reuses the existing stm32_rproc driver implemented in V19. The devicetree is now structured as follows: firmware { tee_rproc: optee-rproc { compatible = "80a4c275-0a47-4905-8285-1486a9771a08"; }; }; m4: m4@10000000 { compatible = "st,stm32mp1-m4"; reg = <0x10000000 0x40000>, <0x30000000 0x40000>, <0x38000000 0x10000>; mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>, <&ipcc 3>; mbox-names = "vq0", "vq1", "shutdown", "detach"; memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>, <&vdev0vring1>, <&vdev0buffer>, <&retram>; interrupt-parent = <&exti>; interrupts = <68 1>; st,rproc-tee = <&tee_rproc 0>; status = "okay"; }; As a consequence, this version: - reintroduce v19 commits for stm32_rproc.c driver , adding the support of the st,rproc-tee binding. - drops the dedicated remoteproc-tee.yaml and st,stm32-rproc-tee.yaml bindings from the series. - extends st,stm32-rproc.yaml with st,rproc-tee to describe the link to the TEE remoteproc backend. - removes the dedicated stm32_rproc_tee.c driver and reuses stm32_rproc.c for both native and TEE-controlled cases. - keeps remoteproc_tee.c aligned with the phandle-based lookup introduced in v21 and uses a device_link between the STM32 remoteproc instance and the TEE backend device. More details are available in each patch commit message. Main updates from version V20[3]: -------------------------------- To address Rob’s concern on v20concerning resource declaration under the tee node, the device tree is now structured as follows,replacing the child-parent hierarchy with a phandle: firmware { tee_rproc: optee-rproc { compatible = "80a4c275-0a47-4905-8285-1486a9771a08"; }; }; m4: m4@0 { compatible = "st,stm32mp1-m4-tee"; reg = <0 0>; mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>; mbox-names = "vq0", "vq1", "shutdown"; memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>, <&vdev0vring1>, <&vdev0buffer>, <&retram>; interrupt-parent = <&exti>; interrupts = <68 1>; rproc-tee-phandle = <&tee_rproc 0>; st,auto-boot; wakeup-source; status = "okay"; }; As a consequence, this version: - Updates the device tree and bindings to: - Change the compatible property from "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" to "80a4c275-0a47-4905-8285-1486a9771a08". - Use the rproc-tee-phandle to avoid the parent-child hierarchy. - Updates stm32_rproc_tee.c and remoteproc_tee.c to adapt to the new bindings. - Updates remoteproc_tee.c to compute the device tree compatible string from the TEE UUID. Main updates from version V19[4]: -------------------------------- The devicetree is now structured as follows: firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; #address-cells = <1>; #size-cells = <0>; rproc-service@0 { compatible = "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08"; reg = <0>; #address-cells = <1>; #size-cells = <0>; status = "okay"; m4: m4@0 { compatible = "st,stm32mp15-m4-tee"; reg = <0>; mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>; mbox-names = "vq0", "vq1", "shutdown"; memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>, <&vdev0vring1>, <&vdev0buffer>, <&retram>; interrupt-parent = <&exti>; interrupts = <68 1>; status = "okay"; }; }; }; }; As a consequence, this version: - Introduces a new stm32_rproc_tee.c remoteproc driver. Instead of further complicating the existing stm32_rproc.c driver, a dedicated TEE-based driver is added. Both drivers are intended to also support the STM32MP2x Cortex-M33 remote processor in a next step. - Reworks the bindings: - Drop the st,stm32-rproc.yaml updates that were introduced in previous revisions. - Add remoteproc-tee.yaml for the "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" compatible. - Add st,stm32-rproc-tee.yaml for the "st,stm32mp15-m4-tee" compatible. - Reworks the probing sequence: The m4@0 device is now probed by the remoteproc-tee driver, which itself is instantiated by the TEE (OP-TEE) bus. More details are available in each patch commit message. [1] https://lore.kernel.org/linux-remoteproc/20260317180329.1207625-1-arnaud.po… [2] https://lore.kernel.org/linux-remoteproc/20251217153917.3998544-1-arnaud.po… [3] https://lore.kernel.org/linux-devicetree/20250625094028.758016-1-arnaud.pou… Tested-on: --------- commit 591cd656a1bf ("Linux 7.0-rc7") Description of the feature: -------------------------- This series proposes the implementation of a remoteproc tee driver to communicate with a TEE trusted application responsible for authenticating and loading the remoteproc firmware image in an Arm secure context. 1) Principle: The remoteproc tee driver provides services to communicate with the OP-TEE trusted application running on the Trusted Execution Context (TEE). The trusted application in TEE manages the remote processor lifecycle: - authenticating and loading firmware images, - isolating and securing the remote processor memories, - supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33), - managing the start and stop of the firmware by the TEE. 2) Format of the signed image: Refer to: https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc… 3) OP-TEE trusted application API: Refer to: https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem… 4) OP-TEE signature script Refer to: https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py Example of usage: sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem 5) Impact on User space Application No sysfs impact. The user only needs to provide the signed firmware image instead of the ELF image. For more information about the implementation, a presentation is available here (note that the format of the signed image has evolved between the presentation and the integration in OP-TEE). https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds Arnaud Pouliquen (7): dt-bindings: firmware: Add TEE remoteproc service binding dt-bindings: remoteproc: st,stm32-rproc: add st,rproc-tee remoteproc: core: Introduce rproc_pa_to_va helper remoteproc: Introduce optional release_fw operation remoteproc: Add TEE support remoteproc: stm32: Create sub-functions to request shutdown and release remoteproc: stm32: Add support of an OP-TEE TA to load the firmware .../bindings/remoteproc/remoteproc-tee.yaml | 36 + .../bindings/remoteproc/st,stm32-rproc.yaml | 55 +- drivers/remoteproc/Kconfig | 10 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/remoteproc_core.c | 56 ++ drivers/remoteproc/remoteproc_internal.h | 6 + drivers/remoteproc/remoteproc_tee.c | 789 ++++++++++++++++++ drivers/remoteproc/stm32_rproc.c | 249 ++++-- include/linux/remoteproc.h | 6 + include/linux/remoteproc_tee.h | 98 +++ 10 files changed, 1220 insertions(+), 86 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/remoteproc-tee.yaml create mode 100644 drivers/remoteproc/remoteproc_tee.c create mode 100644 include/linux/remoteproc_tee.h base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2 -- 2.43.0

2 months, 1 week

1
7
0 0

PKCS#11 TA needs userland supplicant?

by Jan Kiszka

Hi all, to avoid that I'm debugging further this error I get during boot with CONFIG_RPMB=y in the kernel and CFG_IN_TREE_EARLY_TAS=pkcs11/fd02c9da...: [ 0.359372] mmcblk0boot0: mmc0:0001 QEMU!! 4.00 MiB [ 0.361779] mmcblk0boot1: mmc0:0001 QEMU!! 4.00 MiB [ 0.363761] mmcblk0rpmb: mmc0:0001 QEMU!! 2.00 MiB, chardev (248:0) D/TC:? 0 tee_ta_init_session_with_context:569 Re-open trusted service 7011a688-ddde-4053-a5a9-7b3c4ddf13b8 D/TC:? 0 legacy_rpmb_init:1143 Trying legacy RPMB init E/TC:? 0 get_rpc_alloc_res:646 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2 D/TC:? 0 tee_ta_invoke_command:830 Error: f0100003 of 4 D/TC:? 0 tee_ta_close_session:469 csess 0xc0210910 id 1 D/TC:? 0 tee_ta_close_session:488 Destroy session Is it possible at all to run the PKCS#11 TA without userland tee- supplicant? I thought it only needs the supplicant for RPMB, thus should be fine with the in-kernel routing (which is active), but maybe that is not true. All is fine - minus that error message - if I later on start tee- supplicant and use the PKCS#11 TA then. Thanks, Jan -- Siemens AG, Foundational Technologies Linux Expert Center

2 months, 2 weeks

2
7
0 0

Preparing for OP-TEE 4.10.0

by Jens Wiklander

[BCC all OP-TEE maintainers] Hi OP-TEE maintainers & contributors, OP-TEE version 4.10.0 is now scheduled for release on 2026-04-17. So, now is a good time to start testing the master branch across various platforms and report or fix any bugs. The GitHub pull request for collecting Tested-by tags or any other comments is https://github.com/OP-TEE/optee_os/pull/7753. We will create the release candidate tag 4.10.0-rc1 this Friday, April 3. You can find more information related to releases here: https://optee.readthedocs.io/en/latest/general/releases.html Thanks, Jens

2 months, 3 weeks

1
1
0 0

OP-TEE: memory corruption in scmi_pin_control_list_associations_handler()

by Dan Carpenter

When we do SCMI on OP-TEE, the in buffer and out buffer are the same buffer. I added some debug code to confirm this: diff --git a/module/msg_smt/src/mod_msg_smt.c b/module/msg_smt/src/mod_msg_smt.c index 853fe66b8d27..1e92dcd49c29 100644 --- a/module/msg_smt/src/mod_msg_smt.c +++ b/module/msg_smt/src/mod_msg_smt.c @@ -175,6 +175,11 @@ static int smt_write_payload(fwk_id_t channel_id, if (!channel_ctx->locked) return FWK_E_ACCESS; + FWK_LOG_ERR("OUT=%p IN=%p %s", + channel_ctx->out->payload, + channel_ctx->in->payload, + (channel_ctx->out->payload == channel_ctx->in->payload) ? "equal" : "different"); + memcpy(((uint8_t*)channel_ctx->out->payload) + offset, payload, size); return FWK_SUCCESS; And it's true: [ 0.000000] OUT=0x9c401004 IN=0x9c401004 equal This normally isn't a problem because we read a few inputs at the start of the function and then write out the result to the output at the end. But in the scmi_pin_control_list_associations_handler() it does a loop where each iteration reads from parameters->index which is input and writes to the output with scmi_pin_control_ctx.scmi_api->write_payload() and that corrupts the input data. Copying the input buffer to a the stack the issue for me, but I feel like it is a hack. It would be better to use separate buffers for input and output. I think this comes from: https://github.com/OP-TEE/optee_os/blob/master/core/kernel/pseudo_ta.c#L93 I added a print statement to there as well: diff --git a/core/kernel/pseudo_ta.c b/core/kernel/pseudo_ta.c index 587faa41a770..426870fb934c 100644 --- a/core/kernel/pseudo_ta.c +++ b/core/kernel/pseudo_ta.c @@ -90,6 +90,7 @@ static TEE_Result copy_in_param(struct ts_session *s __maybe_unused, va = NULL; } + EMSG("n=%lu va=%p", n, va); tee_param[n].memref.buffer = va; tee_param[n].memref.size = mem->size; break; E/TC:? 0 copy_in_param:93 n=1 va=0x9c401000 E/TC:? 0 copy_in_param:93 n=2 va=0x9c401000 Here is the patch to save "parameters" to a different buffer. --- .../scmi_pin_control/src/mod_scmi_pin_control.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/module/scmi_pin_control/src/mod_scmi_pin_control.c b/module/scmi_pin_control/src/mod_scmi_pin_control.c index a0b90dd2b73f..54e613b70f69 100644 --- a/module/scmi_pin_control/src/mod_scmi_pin_control.c +++ b/module/scmi_pin_control/src/mod_scmi_pin_control.c @@ -344,7 +344,7 @@ static int scmi_pin_control_list_associations_handler( fwk_id_t service_id, const uint32_t *payload) { - const struct scmi_pin_control_list_associations_a2p *parameters; + const struct scmi_pin_control_list_associations_a2p parameters; uint32_t payload_size; uint16_t identifiers_count; uint16_t total_number_of_associations; @@ -362,8 +362,9 @@ static int scmi_pin_control_list_associations_handler( payload_size = (uint32_t)sizeof(return_values); parameters = (const struct scmi_pin_control_list_associations_a2p *)payload; + memcpy(&parameters, payload, sizeof(parameters)); - status = map_identifier(parameters->identifier, &mapped_identifier); + status = map_identifier(parameters.identifier, &mapped_identifier); if (status != FWK_SUCCESS) { return_values.status = SCMI_NOT_FOUND; @@ -371,7 +372,7 @@ static int scmi_pin_control_list_associations_handler( } status = scmi_pin_control_ctx.pinctrl_api->get_total_number_of_associations( - mapped_identifier, parameters->flags, &total_number_of_associations); + mapped_identifier, parameters.flags, &total_number_of_associations); if (status != FWK_SUCCESS) { return_values.status = SCMI_NOT_FOUND; goto exit; @@ -388,11 +389,11 @@ static int scmi_pin_control_list_associations_handler( identifiers_count = (uint16_t)FWK_MIN( buffer_allowed_identifiers, - (uint16_t)(total_number_of_associations - parameters->index)); + (uint16_t)(total_number_of_associations - parameters.index)); return_values.flags = identifiers_count; return_values.flags |= SHIFT_LEFT_BY_POS( - (total_number_of_associations - parameters->index - identifiers_count), + (total_number_of_associations - parameters.index - identifiers_count), NUM_OF_REMAINING_ELEMENTS_POS); for (identifier_index = 0; identifier_index < identifiers_count; @@ -401,8 +402,8 @@ static int scmi_pin_control_list_associations_handler( status = scmi_pin_control_ctx.pinctrl_api->get_list_associations( mapped_identifier, - parameters->flags, - (parameters->index + identifier_index), + parameters.flags, + (parameters.index + identifier_index), &object_id); if (status != FWK_SUCCESS) { return_values.status = SCMI_NOT_FOUND; -- 2.51.0

2 months, 3 weeks

2
3
0 0

Possible race during OP-TEE kernel module device probing

by Shf Chen (陳少甫)

Hi, We found a possible race condition issue during OP-TEE kernel driver probing the device. A NULL pointer dereference exception can happen when another kernel driver open OP-TEE context with tee_client_open_context() then do a SMC call to OP-TEE. Below is the exception: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000001026bb000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Workqueue: events_unbound deferred_probe_work_func pstate: 03400005 (nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : optee_cq_wait_init+0x78/0x124 [optee] lr : optee_cq_wait_init+0x60/0x124 [optee] sp : ffffffc081fcb7f0 x29: ffffffc081fcb7f0 x28: 0000000000000000 x27: 0000000000001000 x26: ffffff8080e42c60 x25: ffffff8084d46040 x24: 0000000000000000 x23: 0000000000000000 x22: ffffffc081fcb8c0 x21: ffffffc081fcb8a8 x20: 0000000000000000 x19: ffffff8082741570 x18: ffffffe572f8ca00 x17: 00000000fa28650f x16: 00000000fa28650f x15: ffffff8084d47000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000084d47000 x11: 0000000000000000 x10: 0000000032000012 x9 : 04d4600000000001 x8 : ffffffc081fcb8c8 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffffff83c86649e0 x4 : 0000000000000008 x3 : 0000000000000000 x2 : ffffff80827415a0 x1 : 0000000000000000 x0 : ffffffc081fcb8c0 Call trace: optee_cq_wait_init+0x78/0x124 [optee f6dbc35f8d96acbe1f3c329d72018151d796208d] optee_smc_do_call_with_arg+0x12c/0x95c [optee f6dbc35f8d96acbe1f3c329d72018151d796208d] optee_shm_register+0x284/0x360 [optee f6dbc35f8d96acbe1f3c329d72018151d796208d] register_shm_helper+0x1a4/0x2f4 [tee cdd8a0d077d984bda1f31f9e8903836edbe46603] tee_shm_register_kernel_buf+0x60/0x90 [tee cdd8a0d077d984bda1f31f9e8903836edbe46603] cmdq_sec_allocate_wsm+0x58/0xc4 [mtk_cmdq_sec_mbox ac82dc958e32252a21c6ce55bb8839ebb288387a] cmdq_sec_probe+0x80/0x4a0 [mtk_cmdq_sec_mbox ac82dc958e32252a21c6ce55bb8839ebb288387a] We found the optee->call_queue hasn't been initialized when our driver called OP-TEE, and it might have some issues about the device data structure initialize order in optee_probe()[drivers/tee/optee/smc_abi.c]: --- rc = tee_device_register(optee->teedev); // <----- TEE device register here if (rc) goto err_unreg_supp_teedev; rc = tee_device_register(optee->supp_teedev); if (rc) goto err_unreg_supp_teedev; optee_cq_init(&optee->call_queue, thread_count); // <----- Some data structures are initialized afterwards optee_supp_init(&optee->supp); optee->smc.memremaped_shm = memremaped_shm; optee->pool = pool; optee_shm_arg_cache_init(optee, arg_cache_flags); mutex_init(&optee->rpmb_dev_mutex); --- We want to ask if the data structure initialization should be done before the tee device registration? Best regards, Shao-Fu Chen

2 months, 3 weeks

3
4
0 0

[PATCH v2 00/15] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures with S-EL2 and Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Surely the backwards compatibility is maintained and tested for SCM backend. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#13: migrates all client drivers to generic PAS service. - Patch #14: drops legacy PAS SCM exported APIs. The patch-set is based on v7.0-rc2 tag and can be found in git tree here [2]. Merge strategy: It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… --- Changes in v2: - Fixed kernel doc warnings. - Polish commit message and comments for patch #2. - Pass proper PAS ID in set_remote_state API for media firmware drivers. - Added Maintainer entry and dropped MODULE_AUTHOR. - Picked up ack from Jeff. Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (14): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS_TEE service backend drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers MAINTAINERS: Add maintainer entry for Qualcomm PAS TZ service MAINTAINERS | 9 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 18 + drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 298 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 53 ++ drivers/firmware/qcom/qcom_pas_tee.c | 477 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 304 ++++------- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/ahb.c | 8 +- drivers/remoteproc/Kconfig | 1 + drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 41 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 23 files changed, 1108 insertions(+), 303 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

2 months, 3 weeks

6
40
0 0

[GIT PULL] OP-TEE update for 7.1

by Jens Wiklander

Hello soc maintainers, Please pull this small patch simlifying the OP-TEE context matching logic. Thanks, Jens The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f: Linux 7.0-rc1 (2026-02-22 13:18:59 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/optee-for-v7.1 for you to fetch changes up to 8c6e843f1c26a0b12720cab02f785c46450b6adc: optee: simplify OP-TEE context match (2026-03-04 08:33:31 +0100) ---------------------------------------------------------------- OP-TEE update for 7.1 Simplify TEE implementor ID match logic ---------------------------------------------------------------- Rouven Czerwinski (1): optee: simplify OP-TEE context match drivers/tee/optee/device.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)

2 months, 4 weeks

1
0
0 0

[GIT PULL] TEE update for 7.1

by Jens Wiklander

Hello soc maintainers, Please pull this small patch cleaning up kernel-doc comments in tee_core.h. Thanks, Jens The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f: Linux 7.0-rc1 (2026-02-22 13:18:59 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-for-v7.1 for you to fetch changes up to e416e7fa417b2d2604c1526a2f9cc38da7ced166: tee: clean up tee_core.h kernel-doc (2026-03-13 08:22:54 +0100) ---------------------------------------------------------------- TEE update for 7.1 Clean up tee_core.h kernel-doc to eliminate build warnings ---------------------------------------------------------------- Randy Dunlap (1): tee: clean up tee_core.h kernel-doc include/linux/tee_core.h | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-)

2 months, 4 weeks

1
0
0 0

[PATCH 00/14] firmware: qcom: Add OP-TEE PAS service support

by Sumit Garg

From: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to QTEE can't support these non- standard SCM calls. And even for newer architectures QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Currently OP-TEE support is being added to provide the backend PAS service implementation which can be found as part of this PR [1]. This implementation has been tested on Kodiak/RB3Gen2 board with lemans EVK board being the next target. In addition to that WIN/IPQ targets planning to use OP-TEE will use this service too. Patch summary: - Patch #1: adds Kodiak EL2 overlay since boot stack with TF-A/OP-TEE only allow UEFI and Linux to boot in EL2. - Patch #2: adds generic PAS service. - Patch #3: migrates SCM backend to generic PAS service. - Patch #4: adds TEE/OP-TEE backend for generic PAS service. - Patch #5-#13: migrates all client drivers to generic PAS service. - Patch #14: drops legacy PAS SCM exported APIs. The patch-set is based on v7.0-rc2 tag and can be found in git tree here [2]. Merge strategy: ---------------- It is expected due to APIs dependency, the entire patch-set to go via the Qcom tree. All other subsystem maintainers, it will be great if I can get acks for the corresponding subsystem patches. [1] https://github.com/OP-TEE/optee_os/pull/7721 [2] https://git.kernel.org/pub/scm/linux/kernel/git/sumit.garg/linux.git/log/?h… Mukesh Ojha (1): arm64: dts: qcom: kodiak: Add EL2 overlay Sumit Garg (13): firmware: qcom: Add a generic PAS service firmware: qcom_scm: Migrate to generic PAS service firmware: qcom: Add a PAS TEE service remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs soc: qcom: mdtloader: Switch to generic PAS TZ APIs remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs remoteproc: qcom: Select QCOM_PAS_TEE service backend drm/msm: Switch to generic PAS TZ APIs media: qcom: Switch to generic PAS TZ APIs net: ipa: Switch to generic PAS TZ APIs wifi: ath12k: Switch to generic PAS TZ APIs firmware: qcom_scm: Remove SCM PAS wrappers arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/kodiak-el2.dtso | 35 ++ drivers/firmware/qcom/Kconfig | 18 + drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 295 +++++++++++ drivers/firmware/qcom/qcom_pas.h | 53 ++ drivers/firmware/qcom/qcom_pas_tee.c | 478 ++++++++++++++++++ drivers/firmware/qcom/qcom_scm.c | 304 ++++------- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 +- .../media/platform/qcom/iris/iris_firmware.c | 9 +- drivers/media/platform/qcom/venus/firmware.c | 11 +- drivers/net/ipa/ipa_main.c | 13 +- drivers/net/wireless/ath/ath12k/ahb.c | 8 +- drivers/remoteproc/Kconfig | 1 + drivers/remoteproc/qcom_q6v5_mss.c | 5 +- drivers/remoteproc/qcom_q6v5_pas.c | 51 +- drivers/remoteproc/qcom_wcnss.c | 12 +- drivers/soc/qcom/mdt_loader.c | 12 +- include/linux/firmware/qcom/qcom_pas.h | 41 ++ include/linux/firmware/qcom/qcom_scm.h | 29 -- include/linux/soc/qcom/mdt_loader.h | 6 +- 22 files changed, 1097 insertions(+), 303 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/kodiak-el2.dtso create mode 100644 drivers/firmware/qcom/qcom_pas.c create mode 100644 drivers/firmware/qcom/qcom_pas.h create mode 100644 drivers/firmware/qcom/qcom_pas_tee.c create mode 100644 include/linux/firmware/qcom/qcom_pas.h -- 2.51.0

2 months, 4 weeks

9
38
0 0

[GIT PULL] TEE shared memory fix for 7.0

by Jens Wiklander

Hello arm-soc maintainers, Please pull this patch removing the refcounting of kernel pages within the TEE shared memory helper. Thanks, Jens The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f: Linux 7.0-rc1 (2026-02-22 13:18:59 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git tags/tee-fix-for-v7.0 for you to fetch changes up to 08d9a4580f71120be3c5b221af32dca00a48ceb0: tee: shm: Remove refcounting of kernel pages (2026-03-03 09:03:04 +0100) ---------------------------------------------------------------- TEE shared memory update for 7.0 Remove refcounting of kernel pages in register_shm_helper() to support slab allocations. ---------------------------------------------------------------- Matthew Wilcox (1): tee: shm: Remove refcounting of kernel pages drivers/tee/tee_shm.c | 27 --------------------------- 1 file changed, 27 deletions(-)

3 months

5
5
0 0

OP-TEE Contributions Forum, monthly meeting March 24

by Jens Wiklander

Hi, Tomorrow, Tuesday, it's time for another LOC monthly meeting. For time and connection details, see the calendar at https://www.trustedfirmware.org/meetings/ - OP-TEE version 4.10.0 to be released April 17 - Marco Felsch is working on initial Kconfig support: https://github.com/OP-TEE/optee_os/pull/7714 + How to configure? Vanilla "make defconfig" and friends? Should we support passing "CFG_XXX=y" on the command line for convenience? In a one-step or two-step operation? + Integration with the build git: Do we need a way to ensure the active configuration matches what the build git expects? + Is it possible to make a seamless transition (with no visible external changes) when building OP-TEE? If so, do we want it? Any other topics? Cheers, Jens

3 months

1
0
0 0

[PATCH v21 0/6] Introduction of a remoteproc tee to load signed firmware

by Arnaud Pouliquen

Main updates from version V20[4]: -------------------------------- To address Rob’s concern on v20concerning resource declaration under the tee node, the device tree is now structured as follows,replacing the child-parent hierarchy with a phandle: firmware { tee_rproc: optee-rproc { compatible = "80a4c275-0a47-4905-8285-1486a9771a08"; }; }; m4: m4@0 { compatible = "st,stm32mp1-m4-tee"; reg = <0 0>; mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>; mbox-names = "vq0", "vq1", "shutdown"; memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>, <&vdev0vring1>, <&vdev0buffer>, <&retram>; interrupt-parent = <&exti>; interrupts = <68 1>; rproc-tee-phandle = <&tee_rproc 0>; st,auto-boot; wakeup-source; status = "okay"; }; As a consequence, this version: - Updates the device tree and bindings to: - Change the compatible property from "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" to "80a4c275-0a47-4905-8285-1486a9771a08". - Use the rproc-tee-phandle to avoid the parent-child hierarchy. - Updates stm32_rproc_tee.c and remoteproc_tee.c to adapt to the new bindings. - Updates remoteproc_tee.c to compute the device tree compatible string from the TEE UUID. Main updates from version V19[3]: -------------------------------- The devicetree is now structured as follows: firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; #address-cells = <1>; #size-cells = <0>; rproc-service@0 { compatible = "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08"; reg = <0>; #address-cells = <1>; #size-cells = <0>; status = "okay"; m4: m4@0 { compatible = "st,stm32mp15-m4-tee"; reg = <0>; mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>; mbox-names = "vq0", "vq1", "shutdown"; memory-region = <&vdev0vring0>, <&m_ipc_shm>, <&mcuram2>, <&vdev0vring1>, <&vdev0buffer>, <&retram>; interrupt-parent = <&exti>; interrupts = <68 1>; status = "okay"; }; }; }; }; As a consequence, this version: - Introduces a new stm32_rproc_tee.c remoteproc driver. Instead of further complicating the existing stm32_rproc.c driver, a dedicated TEE-based driver is added. Both drivers are intended to also support the STM32MP2x Cortex-M33 remote processor in a next step. - Reworks the bindings: - Drop the st,stm32-rproc.yaml updates that were introduced in previous revisions. - Add remoteproc-tee.yaml for the "rproc-service-80a4c275-0a47-4905-8285-1486a9771a08" compatible. - Add st,stm32-rproc-tee.yaml for the "st,stm32mp15-m4-tee" compatible. - Reworks the probing sequence: The m4@0 device is now probed by the remoteproc-tee driver, which itself is instantiated by the TEE (OP-TEE) bus. Main updates from version V18[2]: -------------------------------- - rework documentation for the release_fw ops - rework function documentation in remoteproc_tee.c - replace spinlock by mutex and generalize usage in remoteproc_tee.c Main updates from version V17[1]: -------------------------------- - Fix: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing More details are available in each patch commit message. [1] https://lore.kernel.org/linux-remoteproc/20250613091650.2337411-1-arnaud.po… [2] https://lore.kernel.org/linux-remoteproc/20250616075530.4106090-1-arnaud.po… [3] https://lore.kernel.org/linux-devicetree/20250625094028.758016-1-arnaud.pou… [3] https://lore.kernel.org/linux-remoteproc/20251217153917.3998544-1-arnaud.po… Tested-on: --------- commit 1f318b96cc84 ("Linux 7.0-rc3") Description of the feature: -------------------------- This series proposes the implementation of a remoteproc tee driver to communicate with a TEE trusted application responsible for authenticating and loading the remoteproc firmware image in an Arm secure context. 1) Principle: The remoteproc tee driver provides services to communicate with the OP-TEE trusted application running on the Trusted Execution Context (TEE). The trusted application in TEE manages the remote processor lifecycle: - authenticating and loading firmware images, - isolating and securing the remote processor memories, - supporting multi-firmware (e.g., TF-M + Zephyr on a Cortex-M33), - managing the start and stop of the firmware by the TEE. 2) Format of the signed image: Refer to: https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/src/remoteproc… 3) OP-TEE trusted application API: Refer to: https://github.com/OP-TEE/optee_os/blob/master/ta/remoteproc/include/ta_rem… 4) OP-TEE signature script Refer to: https://github.com/OP-TEE/optee_os/blob/master/scripts/sign_rproc_fw.py Example of usage: sign_rproc_fw.py --in <fw1.elf> --in <fw2.elf> --out <signed_fw.sign> --key ${OP-TEE_PATH}/keys/default.pem 5) Impact on User space Application No sysfs impact. The user only needs to provide the signed firmware image instead of the ELF image. For more information about the implementation, a presentation is available here (note that the format of the signed image has evolved between the presentation and the integration in OP-TEE). https://resources.linaro.org/en/resource/6c5bGvZwUAjX56fvxthxds Arnaud Pouliquen (6): dt-bindings: firmware: Add TEE remoteproc service binding dt-bindings: remoteproc: Add STM32 TEE-controlled rproc binding remoteproc: core: Introduce rproc_pa_to_va helper remoteproc: Introduce optional release_fw operation remoteproc: Add TEE support remoteproc: stm32: Add TEE-controlled STM32 driver .../bindings/remoteproc/remoteproc-tee.yaml | 36 + .../remoteproc/st,stm32-rproc-tee.yaml | 108 +++ drivers/remoteproc/Kconfig | 10 + drivers/remoteproc/Makefile | 3 +- drivers/remoteproc/remoteproc_core.c | 52 ++ drivers/remoteproc/remoteproc_internal.h | 6 + drivers/remoteproc/remoteproc_tee.c | 810 ++++++++++++++++++ drivers/remoteproc/stm32_rproc_tee.c | 537 ++++++++++++ include/linux/remoteproc.h | 6 + include/linux/remoteproc_tee.h | 91 ++ 10 files changed, 1658 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/remoteproc-tee.yaml create mode 100644 Documentation/devicetree/bindings/remoteproc/st,stm32-rproc-tee.yaml create mode 100644 drivers/remoteproc/remoteproc_tee.c create mode 100644 drivers/remoteproc/stm32_rproc_tee.c create mode 100644 include/linux/remoteproc_tee.h base-commit: 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681 -- 2.43.0

3 months

3
12
0 0

[PATCH] optee: Check return value of tee_shm_get_va()

by Chen Ni

The function tee_shm_get_va() can return an error pointer if the shared memory is not properly mapped or if the offset is invalid. Without this check, passing the error pointer to subsequent memory operations could lead to a kernel panic. Add a check for IS_ERR() on the return value of tee_shm_get_va(). Fixes: f0c8431568ee ("optee: probe RPMB device using RPMB subsystem") Signed-off-by: Chen Ni <nichen(a)iscas.ac.cn> --- drivers/tee/optee/rpc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c index b0ed4cb49452..32f7742c094c 100644 --- a/drivers/tee/optee/rpc.c +++ b/drivers/tee/optee/rpc.c @@ -393,6 +393,11 @@ static void handle_rpc_func_rpmb_frames(struct tee_context *ctx, params[0].u.memref.shm_offs); p1 = tee_shm_get_va(params[1].u.memref.shm, params[1].u.memref.shm_offs); + if (IS_ERR(p0) || IS_ERR(p1)) { + arg->ret = TEEC_ERROR_BAD_PARAMETERS; + goto out; + } + if (rpmb_route_frames(rdev, p0, params[0].u.memref.size, p1, params[1].u.memref.size)) { arg->ret = TEEC_ERROR_BAD_PARAMETERS; -- 2.25.1

3 months, 1 week

4
4
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE