- OP-TEE - lists.trustedfirmware.org

[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

4 weeks

3
2
0 0

OP-TEE going forward

by Joakim Bech

Hi, OP-TEE has been running successfully as an open source project since 2014 and can be considered a mature project. It is widely used in various applications and devices, used by both small and large companies and it has an active community. Although ownership transferred from Linaro to TrustedFirmware a couple of years ago, the core activities around OP-TEE has been mainly been done by Linaro employees and assignees (engineers from other companies working with Linaro). However, with time things change. The core maintainers [1] have moved on to other companies and we're now in a situation that none of the core maintainers are working for Linaro anymore. Although we as core maintainers have expressed willingness to continue contributing to the project, OP-TEE is no longer the only project we are working on and therefore we cannot commit as much time to the project as we used to. With that there are some open questions like, who is ultimately responsible for the project, who administers mailing lists, merge patches, responds to security incident reports, run monthly meetings an who is the one making releases? Since this touches legal aspects and plain permissions, we will work with Linaro to try to find a solution to this situation, but this also means that we're looking for new/additional maintainers to help with the project. Maintainers that can commit time to the project and help with the day-to-day activities. A direct consequence of this situation is that we will not be able to make the release meant to be released July 17th 2026 [2]. That release has been dropped and we instead aim to make the next release in October 2026. If you are interested in helping out with the project, please reach out to us on the mailing list or directly to any of the core maintainers. We are happy to discuss what it means to be a maintainer and what kind of help we are looking for. [1] https://github.com/OP-TEE/optee_os/blob/7c38cc358e36a8b74a3fefedb0c5c7f78be… [2] https://optee.readthedocs.io/en/latest/general/releases.html // Regards, Joakim, Jens, Jerome and Etienne.

1 month

1
0
0 0

Critical Vulnerabilities in OP-TEE/libfdt - CVE Assignment Request

by Brand Unit

*Dear TrustedFirmware Security Team, * *We have discovered 4 critical vulnerabilities in OP-TEE and libfdt:* 1. Integer Underflow in PKCS#11 RSA-AES Key Unwrap (High) 2. Integer Underflow → Stack Buffer Overflow (High) 3. Heap Underflow in overlay_symbol_update() (High) 4. Heap Buffer Overflow in fdt_next_tag() (High) *All vulnerabilities have been: * ✓ Responsibly disclosed via GitHub Security Advisory (embargoed) ✓ Documented with PoC and technical analysis ✓ Reported to Intigriti GitHub Advisory (embargoed until Sept 24, 2026): [ GitHub link <https://github.com/OP-TEE/optee_os/security/advisories/GHSA-w85w-hp72-j33g> ] *We are requesting: * *1. Formal CVE assignment * * 2. Timeline for patch release * * 3. Acknowledgment in security advisory* PoC inputs and detailed technical documentation available. Contact: mehedi100 (mehedi100@... if you need direct contact) Regards, Mehedi Hasan

1 month

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

1 month

3
6
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

1 month

4
20
0 0

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

1 month

1
0
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 month

1
0
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 month

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 month, 1 week

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 month, 2 weeks

3
11
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE