- OP-TEE - lists.trustedfirmware.org

[RFC PATCH v1 0/6] tee: optee: RISC-V support over the RPMI TEE service group

by marouene.boubakri＠oss.nxp.com

From: Marouene Boubakri <marouene.boubakri(a)oss.nxp.com> On RISC-V, OP-TEE runs as a supervisor domain isolated from Linux by the M-mode firmware. There is no SMC or HVC instruction: the firmware has to switch the calling hart between the two domains, and the way Linux asks for that switch has to come from the RISC-V specifications rather than from an ad-hoc SBI extension. This series adds RISC-V support to the OP-TEE driver by carrying the existing SMC ABI over the TEE service group of the RISC-V Platform Management Interface (RPMI) [1], sent with the SBI Message Proxy (MPXY) extension of SBI v3.0 [2] through the in-tree MPXY mailbox driver. Each invocation of the SMC ABI becomes a TEE_CALL request whose service data holds the register arguments a0-a7, and whose service response holds the return values a0-a3. The M-mode firmware implementing the service group (the "RPMI TEE framework") switches the calling hart to the OP-TEE domain until OP-TEE responds, so a TEE_CALL behaves like an SMC: it runs on the calling hart and returns when OP-TEE completes the call, requests an RPC or yields on a foreign interrupt. The SMC ABI, the message protocol, RPCs, dynamic and static shared memory and notifications are unchanged, which is why the conduit lives next to the SMCCC one in smc_abi.c instead of being a new ABI like ffa_abi.c. Specification status, and how the series is split: The TEE service group (SERVICEGROUP_ID 0x0010) is part of RPMI v2.0, which is in development: it was added to the main branch of the specification repository in June 2026 [3] and is not in the released RPMI v1.0. Everything in this series that depends on it is kept in the last three patches, which are RFC until RPMI v2.0 is frozen as required by Documentation/arch/riscv/patch-acceptance.rst: - patches 1-3 only rely on SBI v3.0 MPXY and RPMI v1.0 as already supported by the kernel, and on existing OP-TEE driver internals. They are meant to be mergeable on their own; - patches 4-6 add the RPMI v2.0 TEE service group definitions, the binding and the conduit. They implement TEE_CALL as specified; the only OP-TEE specific parts are the content of the service data and service response, which the specification leaves to the service, and the OP-TEE API UID used as service UUID. Why this conduit rather than the alternatives: - A raw ecall to a "TEE" SBI extension, as used by the current OP-TEE OS RISC-V port and by the RISE reference firmware, relies on an EID that does not exist in the SBI specification and on returning four values from an ecall, which the SBI calling convention does not allow. - The RPMI MANAGEMENT_MODE service group (RPMI v1.0) is defined for UEFI PI Management Mode communication and its data is the MM communication buffer; carrying the OP-TEE message protocol in it would go against the specification's intent and collide with its intended users. - An implementation specific service group (0x8000-0xFFFF) is allowed by RPMI v1.0 but would not be a generic OP-TEE conduit. The one non-obvious part is patch 1. An MPXY message send is an ecall on the calling hart, using per-hart shared memory, which returns once the message has been processed. With TEE_CALL that is when OP-TEE has finished running on that hart, which can take an arbitrarily long time. Sending such messages with mbox_send_message() would execute OP-TEE from within msg_submit() with the mailbox channel spinlock held and interrupts disabled, serializing every hart on that lock. Patch 1 adds riscv_sbi_mpxy_mbox_call() to the MPXY mailbox driver, which performs the transfer directly in the calling context with only local interrupts disabled (the per-hart shared memory is also used from hard interrupt context by mbox_send_message() users). Harts proceed in parallel since each one has its own shared memory. The channel is still requested through the mailbox core so that its ownership is tracked. Opinions on whether this belongs in the MPXY driver, or whether the MPXY shared memory handling should move to a core helper usable by several drivers, are welcome. Endpoint identifiers: the framework assigns an identifier to every REE and TEE. The only way for an endpoint to learn them without firmware help is the optional TEE_PROBE_SYSTEM service, whose response is CBOR encoded and cannot be parsed in the kernel, so the binding carries the REE and OP-TEE identifiers as properties that the firmware is expected to fix up in the device tree. Feedback on this is welcome too. Known gaps: - The framework side (OpenSBI: TEE_CALL forwarding through domain context switching) and the messaging return path of the OP-TEE OS RISC-V port are being upstreamed separately. - The service group defines no notification events; OP-TEE asynchronous notifications on RISC-V are left for later and OP-TEE OS does not advertise them on this conduit. - The byte order of the SERVICE UUID field is not specified by RPMI; this series uses the RFC 4122 order. The memory parcel services of the service group are not used, secure world accesses registered pages directly as with the SMC conduit. Testing: built for riscv64 (defconfig plus TEE/OP-TEE, both built-in and as modules) and for arm64 (defconfig plus OP-TEE and FF-A) with W=1 at every step of the series, plus dt_binding_check. [TODO before posting: describe the runtime testing done on QEMU virt with the OpenSBI and OP-TEE OS changes mentioned above, e.g. xtest results.] [1] https://github.com/riscv-non-isa/riscv-rpmi/releases [2] https://github.com/riscv-non-isa/riscv-sbi-doc/releases [3] https://github.com/riscv-non-isa/riscv-rpmi/commits/main/src/srvgrp-tee.adoc Marouene Boubakri (6): mailbox: riscv-sbi-mpxy: add riscv_sbi_mpxy_mbox_call() for hart-local requests tee: optee: select the SMC ABI conduit from the firmware node match data tee: optee: teach the memory type check about RISC-V page attributes mailbox: riscv-rpmi-message: add TEE service group definitions dt-bindings: firmware: add OP-TEE over the RISC-V RPMI TEE service group tee: optee: add a RISC-V conduit over the RPMI TEE service group .../bindings/firmware/linaro,optee-rpmi.yaml | 79 +++++++ Documentation/tee/op-tee.rst | 18 +- MAINTAINERS | 2 + drivers/mailbox/riscv-sbi-mpxy-mbox.c | 60 ++++++ drivers/tee/Kconfig | 2 +- drivers/tee/optee/Kconfig | 11 +- drivers/tee/optee/Makefile | 1 + drivers/tee/optee/call.c | 8 + drivers/tee/optee/optee_private.h | 3 + drivers/tee/optee/optee_rpmi.h | 69 ++++++ drivers/tee/optee/rpmi_conduit.c | 203 ++++++++++++++++++ drivers/tee/optee/smc_abi.c | 41 +++- include/linux/mailbox/riscv-rpmi-message.h | 25 +++ include/linux/mailbox/riscv-sbi-mpxy-mbox.h | 23 ++ 14 files changed, 538 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/firmware/linaro,optee-rpmi.yaml create mode 100644 drivers/tee/optee/optee_rpmi.h create mode 100644 drivers/tee/optee/rpmi_conduit.c create mode 100644 include/linux/mailbox/riscv-sbi-mpxy-mbox.h base-commit: 50d05c7c76c96b90462f24debacca971d2e86713 -- 2.43.0

4 weeks

1
6
0 0

[PATCH v9 00/10] arm64: Unmap FF-A lent memory from direct map

by Vincent Donnefort

This series is a follow-up to the discussion that has started here [1]. While standalone, it also provides primitives reusable for the VPR DMA heap. When memory is lent to the Secure world via FF-A, CPU speculative accesses from NS to the lent pages can still occur as long as it retains a cacheable mapping to it. Ideally, lent memory would be "no-map" but that would mean giving up MiBs of useful memory, so let's try to do better with the help of a CMA pool. On arm64, modifying the direct map at runtime is generally restricted because the linear map defaults to block mapping and splitting blocks at runtime may trigger fatal page fault, unless the CPU implements BBML3 or the entire direct map was mapped at page granularity from boot. Forcing last-level mappings system-wide incurs a severe penalty we want to avoid. Instead, this series introduces targeted last-level mappings for designated memory regions, along with the "arm,ffa-lend-pool" CMA driver to manage unmapping and remapping on lend/reclaim transitions: 1. memblock & OF reserved memory ("ll-map"): - Introduce MEMBLOCK_LLMAP and the DT "ll-map" property for reserved-memory nodes to force last-level (PTE) mappings only for a specific region. 2. set_memory infrastructure: - Introduce can_set_direct_map_range() to check if a specific address range is mapped with last-level entries and can be modified safely. - Introduce __set_direct_map_*() variants that bypass redundant checks when the caller has already validated the range. 3. "arm,ffa-lend-pool" driver - Introduce the "arm,ffa-lend-pool" CMA reserved-memory driver, which unmaps pages prior to lending (ffa_prepare_lend()) and restores them when reclaimed (ffa_lend_reclaimed()). 4. Optee support - Hook OP-TEE dynamic protected memory pools to "arm,ffa-lend-pool" for both SMC (via DT memory-region phandle) and FF-A (via ffa_lend_pool_attach()) transports. Testing: ======== Tested with QEMU v8 using OP-TEE OS (built with CFG_CORE_DYN_PROTMEM=y) under both SMC and FF-A transports [2] static void dump_direct_map(const char *label) { printf("\n=== %s ===\n", label); fflush(stdout); system("sed -n '/Linear Mapping start/,/Linear Mapping end/p' /sys/kernel/debug/kernel_page_tables"); fflush(stdout); } int main(int argc, char *argv[]) { int heap_fd; int dmabuf_fd; struct dma_heap_allocation_data data = { 0 }; size_t size = 1024 * 1024; /* 1MB */ if (argc > 1) size = strtoul(argv[1], NULL, 0); dump_direct_map("BEFORE ALLOCATION"); heap_fd = open("/dev/dma_heap/protected,secure-video", O_RDWR); if (heap_fd < 0) { perror("open /dev/dma_heap/protected,secure-video"); return 1; } printf("\nOpened /dev/dma_heap/protected,secure-video\n"); printf("Allocating %zu bytes of protected memory via DMA heap...\n", size); data.len = size; data.fd_flags = O_RDWR | O_CLOEXEC; if (ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &data) < 0) { perror("ioctl DMA_HEAP_IOCTL_ALLOC"); close(heap_fd); return 1; } dmabuf_fd = data.fd; printf("Successfully allocated %zu bytes! dmabuf_fd = %d\n", size, dmabuf_fd); dump_direct_map("DURING LEND (EXPECT HOLE IN DIRECT MAP)"); printf("\nReleasing dmabuf_fd...\n"); close(dmabuf_fd); close(heap_fd); dump_direct_map("AFTER RECLAIM (RESTORED DIRECT MAP)"); return 0; } [1] https://lore.kernel.org/all/20260807-tegra-vpr-v4-7-5510d16af89e@nvidia.com/ [2] https://optee.readthedocs.io/en/latest/building/gits/build.html#qemu-v8 Vincent Donnefort (10): memblock: Introduce MEMBLOCK_LLMAP of: reserved_mem: Introduce "ll-map" property set_memory.h: Introduce can_set_direct_map_range() set_memory.h: Introduce __set_direct_map*() arm64: can_set_direct_map() if BBML3 arm64: Implement can_set_direct_map_range() arm64: Implement __set_direct_map*() arm64: Add support for MEMBLOCK_LLMAP firmware: arm_ffa: Introduce ffa-lend-pool optee: Add support for arm,ffa-lend-pool arch/arm64/include/asm/set_memory.h | 7 + arch/arm64/mm/mmu.c | 23 ++- arch/arm64/mm/pageattr.c | 67 +++++++- drivers/firmware/arm_ffa/Kconfig | 5 + drivers/firmware/arm_ffa/Makefile | 1 + drivers/firmware/arm_ffa/lend_pool.c | 223 +++++++++++++++++++++++++++ drivers/of/of_reserved_mem.c | 104 ++++++++++--- drivers/tee/optee/ffa_abi.c | 13 +- drivers/tee/optee/protmem.c | 8 - drivers/tee/optee/smc_abi.c | 17 +- drivers/tee/tee_shm.c | 11 +- include/linux/arm_ffa.h | 21 +++ include/linux/memblock.h | 9 ++ include/linux/set_memory.h | 39 +++++ mm/memblock.c | 50 ++++++ 15 files changed, 545 insertions(+), 53 deletions(-) create mode 100644 drivers/firmware/arm_ffa/lend_pool.c base-commit: cee9395acd8043be0644b25c34bfa86623f2b935 -- 2.55.0.970.g62bdec98f9-goog

1 month

4
25
0 0

[PATCH v9 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 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 and lemans EVK boards. In addition to that WIN/IPQ targets tested OP-TEE with 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 generic PAS service. - Patch #2: migrates SCM backend to generic PAS service. - Patch #3: adds TEE/OP-TEE backend for generic PAS service. - Patch #4-#12: migrates all client drivers to generic PAS service. - Patch #13: drops legacy PAS SCM exported APIs. The patch-set is based on v7.2-rc1 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 v9: - Rebased to 7.2-rc1. - Enable SCM backend similar to TEE if ARCH_QCOM is set. - Address misc. comments from Konrad. - Add checks for corner cases (although not reachable as per OP-TEE ABI) reported by Shashiko on patch #3. - Picked up review tags from Konrad. Changes in v8: - Rebased on mainline tip (no functional changes). - Now Lemans EVK is also tested to support OP-TEE PAS here: https://github.com/OP-TEE/optee_os/pull/7845 - Drop Kodiak DT patch as it is carried independently by Mukesh here: https://lore.kernel.org/lkml/20260624063952.2242702-1-mukesh.ojha@oss.qualc… - Regarding Sashiko comments, I have already replied in v6 the ones that don't apply but in v7 I got the same comments again. Specific context reasoning which Shashiko ignores: - ABI contract between Linux and TZ - No support for multiple concurrent backends - The TZ backend doesn’t detach during the entire boot cycle 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. 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 + drivers/firmware/qcom/Kconfig | 22 +- drivers/firmware/qcom/Makefile | 2 + drivers/firmware/qcom/qcom_pas.c | 299 +++++++++++ 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 | 27 +- .../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 +- 26 files changed, 1095 insertions(+), 321 deletions(-) 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.53.0

1 month, 1 week

7
34
0 0

[PATCH AUTOSEL 6.18-5.10] tee: optee: Allow MT_NORMAL_TAGGED shared memory

by Sasha Levin

From: Hirokazu Honda <hiroh(a)chromium.org> [ Upstream commit 1a6e94a8ff32e7879effd1e4a45bf112e506edc1 ] 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> Reviewed-by: Sumit Garg <sumit.garg(a)oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: Connection lost, reconnecting to https://agentn.us.api5.cursor.sh (attempt 1)... Retry attempt 1... # Stable Backport Analysis: `tee: optee: Allow MT_NORMAL_TAGGED shared memory` **Local tree:** Linux 6.18.43 (`git describe HEAD` → `v6.18.43`) --- ## PHASE 1: COMMIT MESSAGE FORENSICS ### Step 1.1: Subject Line **Record:** `[tee: optee]` `[Allow]` — Extend OP-TEE shared-memory validation to accept ARM64 `MT_NORMAL_TAGGED` pages (MTE-tagged normal memory). ### Step 1.2: Tags **Record:** - `Signed-off-by: Hirokazu Honda <hiroh(a)chromium.org>` — author (Chrome team) - `Reviewed-by: Sumit Garg <sumit.garg(a)oss.qualcomm.com>` — OP-TEE maintainer review - `Signed-off-by: Jens Wiklander <jens.wiklander(a)linaro.org>` — TEE subsystem maintainer - No `Fixes:`, `Reported-by:`, `Cc: stable(a)vger.kernel.org`, `Link:`, `Tested-by:`, or `Acked-by:` tags - Notable: Reviewed by subsystem maintainers; no syzbot or crash report ### Step 1.3: Body Analysis **Record:** - **Bug:** On ARM64, userspace buffers mapped with MTE (`PROT_MTE`) use `MT_NORMAL_TAGGED` page attributes. `is_normal_memory()` only accepts `MT_NORMAL`, so `optee_check_mem_type()` rejects valid buffers. - **Symptom:** `-EINVAL` when registering shared memory with OP-TEE; secure-world communication fails for MTE-enabled processes. - **Root cause:** Incomplete memory-type check — `MT_NORMAL_TAGGED` is documented as a normal-memory variant but not recognized by the driver. ### Step 1.4: Hidden Bug Fix? **Record:** No — this is an explicit compatibility fix, not disguised cleanup. It corrects an overly narrow memory-type whitelist. --- ## PHASE 2: DIFF ANALYSIS ### Step 2.1: Inventory **Record:** - **Files:** `drivers/tee/optee/call.c` (+2 / -1) - **Functions:** `is_normal_memory()` only - **Scope:** Single-file, surgical ARM64-only change ### Step 2.2: Code Flow Change **Record:** - **Before:** ARM64 `is_normal_memory()` returns true only for `PTE_ATTRINDX(MT_NORMAL)`. - **After:** Also returns true for `PTE_ATTRINDX(MT_NORMAL_TAGGED)`. - **Path affected:** `optee_check_mem_type()` → `__check_mem_type()` → `is_normal_memory()` during shared-memory registration. ### Step 2.3: Bug Mechanism **Record:** **Logic / correctness fix** — incorrect rejection of a valid ARM64 memory type. Classification: platform-specific compatibility bug (ARM64 MTE + OP-TEE). ### Step 2.4: Fix Quality **Record:** Obviously correct — `arch/arm64/include/asm/memory.h` documents `MT_NORMAL_TAGGED` as the normal-memory type for `PROT_MTE` mappings. Minimal diff, no API changes, no regression risk on non-ARM64 builds (change is inside `#elif defined(CONFIG_ARM64)`). --- ## PHASE 3: GIT HISTORY INVESTIGATION ### Step 3.1: Blame **Record:** `is_normal_memory()` exists in this tree at `call.c:599-609`. The original check (only `MT_NORMAL`) dates to the 2017 introduction of shared-memory type validation (`[PATCH 2/2] tee: optee: check type of registered shared memory`). The stable tree's per- file history is flattened (entire `call.c` attributed to one upstream merge commit), but the function and its `MT_NORMAL`-only check are present in 6.18.43. ### Step 3.2: Fixes Tag **Record:** N/A — no `Fixes:` tag in the commit message. ### Step 3.3: Related File History **Record:** No related follow-up fixes found in this tree. Standalone one-line logical extension. ### Step 3.4: Author Context **Record:** Hirokazu Honda (Chromium). Jens Wiklander is TEE subsystem maintainer; Sumit Garg is OP-TEE maintainer. Both reviewed and accepted. ### Step 3.5: Dependencies **Record:** No prerequisites. `MT_NORMAL_TAGGED` is already defined in `arch/arm64/include/asm/memory.h` (value `1`). MTE userspace support (`PROT_MTE`) is present in this tree. Fix applies standalone. --- ## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH ### Step 4.1: Original Discussion **Record:** Patch submitted Apr 16, 2026. Discussion at [spinics.net msg6157985](https://www.spinics.net/lists/kernel/msg6157985.html). Single-patch submission (not a series). Jens Wiklander: "Looks good. I'm picking up this." Merged via `optee-for-v7.2` tag. No NAKs. ### Step 4.2: Reviewers **Record:** To: Jens Wiklander. Cc: Sumit Garg, op- tee(a)lists.trustedfirmware.org, linux-kernel. Appropriate maintainers involved. ### Step 4.3: Bug Report **Record:** No formal bug report or syzbot link. Real-world motivation from Chrome/Android MTE + OP-TEE integration. ### Step 4.4: Related Patches **Record:** Standalone fix; no series dependencies. ### Step 4.5: Stable List History **Record:** No `Cc: stable` nomination found in review thread. Absence is expected per review pipeline rules and is not a negative signal. --- ## PHASE 5: CODE SEMANTIC ANALYSIS ### Step 5.1: Key Functions **Record:** `is_normal_memory()` (modified), `__check_mem_type()`, `optee_check_mem_type()` (callers unchanged). ### Step 5.2: Callers of `optee_check_mem_type()` **Record:** - `optee_shm_register()` in `smc_abi.c:467` — registers user/kernel shared memory with secure world - `optee_shm_register_supp()` in `smc_abi.c:570` — supplicant path validation - `optee_ffa_shm_register()` in `ffa_abi.c:289` — FF-A ABI shared memory registration ### Step 5.3: Callees **Record:** `__check_mem_type()` walks VMAs via `for_each_vma_range()`, checks `vma->vm_page_prot` against `is_normal_memory()`. ### Step 5.4: Reachability **Record:** Userspace → `/dev/tee*` ioctl `TEE_IOC_SHM_REGISTER` → `tee_ioctl_shm_register()` → `tee_shm_register_user_buf()` → `register_shm_helper()` → `optee_shm_register()` → `optee_check_mem_type()`. **Reachable from userspace** on ARM64 systems with OP-TEE enabled when registering MTE-tagged buffers. ### Step 5.5: Similar Patterns **Record:** `pte_tagged()` in `arch/arm64/include/asm/pgtable.h` uses the same `MT_NORMAL_TAGGED` check pattern. The kernel already treats this as a normal-memory variant elsewhere. --- ## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE (6.18.43) ### Step 6.1: Buggy Code Present? **Record:** **YES.** Current `call.c:605` only checks `MT_NORMAL`: ```605:605:drivers/tee/optee/call.c return (pgprot_val(p) & PTE_ATTRINDX_MASK) == PTE_ATTRINDX(MT_NORMAL); ``` `MT_NORMAL_TAGGED` is defined at `arch/arm64/include/asm/memory.h:172`. MTE support is present (`PROT_MTE` in `Documentation/arch/arm64/memory- tagging-extension.rst`, `arch/arm64/kernel/mte.c`). ### Step 6.2: Backport Complications **Record:** **Clean apply expected** — 2-line change in existing function, identical context to mainline diff. ### Step 6.3: Related Fixes Already Present? **Record:** **No** — `git log --grep="MT_NORMAL_TAGGED"` and `--grep="Allow MT_NORMAL_TAGGED"` return nothing in this tree. Fix not yet applied. --- ## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT ### Step 7.1: Subsystem **Record:** `drivers/tee/optee` — TEE/OP-TEE driver. **Criticality: IMPORTANT** for ARM64 embedded/Android platforms using secure services (Keymaster, DRM, biometrics). Not core kernel, but security- infrastructure relevant on those platforms. ### Step 7.2: Activity **Record:** OP-TEE driver is mature but actively maintained; MTE adoption is an ongoing ARM64 platform concern. --- ## PHASE 8: IMPACT AND RISK ASSESSMENT ### Step 8.1: Who Is Affected **Record:** **Platform-specific:** ARM64 + `CONFIG_OPTEE` + userspace using `PROT_MTE` on buffers shared with OP-TEE. Primarily Android/Chrome OS devices rolling out MTE. ### Step 8.2: Trigger Conditions **Record:** User/application maps anonymous memory with `PROT_MTE`, then registers it with OP-TEE via `TEE_IOC_SHM_REGISTER`. Trigger is deterministic (not a race). Unprivileged users can trigger via TEE ioctl on systems with accessible `/dev/tee*`. ### Step 8.3: Failure Mode Severity **Record:** **`-EINVAL` on shared-memory registration** — TEE/secure- world operations fail entirely for MTE-enabled processes. No crash, corruption, deadlock, or security exploit. **Severity: MEDIUM** (complete functional breakage for affected configuration, but not a stability/security crash). ### Step 8.4: Risk-Benefit **Record:** - **Benefit:** Restores OP-TEE functionality for MTE-enabled ARM64 processes; important for Chrome/Android MTE rollout on TEE-equipped hardware. - **Risk:** Very low — 2 lines, ARM64-only, matches existing kernel semantics for `MT_NORMAL_TAGGED`. - **Ratio:** Favorable — trivial fix, real production impact for a growing platform configuration. --- ## PHASE 9: FINAL SYNTHESIS ### Step 9.1: Evidence Summary **FOR backport:** - Real, reproducible bug in 6.18.43 (buggy code confirmed present) - Small, obviously correct, maintainer-reviewed fix - Userspace-reachable on ARM64 OP-TEE systems - `MT_NORMAL_TAGGED` prerequisite already in tree - Hardware-platform compatibility fix (ARM64 MTE), analogous to quirk/workaround category - Chrome production motivation for growing MTE deployment **AGAINST backport:** - Not a crash, corruption, deadlock, or security vulnerability - Niche configuration (ARM64 + OPTEE + MTE) - No syzbot report or explicit stable nomination - Functional `-EINVAL` rather than kernel oops **Unresolved:** Exact kernel version when MTE userspace + OP-TEE combination became common in production (not needed for decision — bug mechanism is clear). ### Step 9.2: Stable Rules Checklist 1. Obviously correct and tested? **PASS** — logic matches `memory.h` documentation; reviewed by OP-TEE and TEE maintainers. 2. Fixes a real bug affecting users? **PASS** — deterministic `-EINVAL` blocking TEE shared memory for MTE buffers. 3. Important issue? **PASS (borderline)** — not a crash/corruption, but complete breakage of secure-world communication for MTE processes on ARM64 Android/Chrome platforms. 4. Small and contained? **PASS** — 2 lines, 1 file, 1 function. 5. No new features or APIs? **PASS** — extends recognition of existing memory type; no new API. 6. Can apply to local tree? **PASS** — prerequisites present, clean apply expected. ### Step 9.3: Exception Category **Record:** **Hardware/platform workaround** — enables correct handling of ARM64 MTE-tagged normal memory, analogous to the quirk/compatibility exception category in stable rules. ### Step 9.4: Decision Rationale This commit fixes a real compatibility gap between ARM64 MTE (`MT_NORMAL_TAGGED`) and the OP-TEE driver's shared-memory validator. The bug exists in Linux 6.18.43, the fix is trivial and maintainer- approved, and all prerequisites (`MT_NORMAL_TAGGED`, MTE support) are already in this tree. While the failure mode is functional rather than a kernel crash, it completely blocks TEE operations for MTE-enabled processes — a growing concern on ARM64 Android/Chrome platforms where both OP-TEE and MTE are deployed together. The fix is low-risk and fits the stable pattern for small platform compatibility corrections. --- ## Verification - [Phase 1] Parsed subject, tags, body from provided commit message - [Phase 1] Confirmed no `Fixes:`, `Reported-by:`, or `Cc: stable` tags - [Phase 2] Read diff: +2/-1 in `is_normal_memory()`, ARM64 branch only - [Phase 2] Read `call.c:599-642` — confirmed current code only checks `MT_NORMAL` - [Phase 3] `git describe HEAD` → `v6.18.43`; `make kernelversion` → `6.18.43` - [Phase 3] `git blame -L 599,610 drivers/tee/optee/call.c` — function present in tree - [Phase 3] Web search: original `is_normal_memory` introduced ~2017 in OP-TEE shm type check patch - [Phase 3] `git log --grep="Allow MT_NORMAL_TAGGED"` — no match (fix not in tree) - [Phase 4] Fetched spinics.net msg6157985, msg6161595, msg6174403 — maintainer review, no NAKs, no stable Cc - [Phase 4] b4 dig unavailable for commit hash (fix not merged in this tree); used spinics/openwall instead - [Phase 5] `grep optee_check_mem_type` — 3 call sites in `smc_abi.c`, `ffa_abi.c` - [Phase 5] Read `tee_shm.c:496-516` — userspace registration path via `tee_shm_register_user_buf()` - [Phase 5] Read `smc_abi.c:453-469` — `optee_shm_register()` calls `optee_check_mem_type()` - [Phase 6] Confirmed `MT_NORMAL_TAGGED` defined at `arch/arm64/include/asm/memory.h:172` - [Phase 6] Confirmed `pte_tagged()` uses same `MT_NORMAL_TAGGED` pattern in `pgtable.h:191-192` - [Phase 6] `grep PROT_MTE` — MTE userspace support present in tree - [Phase 8] Traced call chain: ioctl → shm register → `optee_check_mem_type()` → `-EINVAL` on MTE buffers **YES**The background `git log -S "is_normal_memory"` search finished. It didn’t turn up a clean introduction point for `is_normal_memory()` in this 6.18.43 stable tree — the hits were unrelated (MIPS) or artifacts of the flattened per-file history (the whole `call.c` lumped under one upstream merge). External history still points to the original OP-TEE shared-memory type check from ~2017. That doesn’t change the earlier conclusion: the buggy `MT_NORMAL`-only check is present in this tree, the fix is small and correct, and it should be backported. **YES** 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 16eb953e14bb6..e422e77b06fb8 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.53.0

1 month, 1 week

1
0
0 0

[PATCH 0/1] tee: fix page pin leak in register_shm_helper()

by Shukai Ni

Hi Jens, This one-patch series fixes a page-pin leak in register_shm_helper() after iov_iter_extract_pages() partially extracts an unaligned user buffer. The cleanup path undercounts the pinned pages by one and loses the final pin when it frees the page array. The issue was reproduced on an x86_64 7.0.0-29-generic kernel with 4 KiB pages. On the unpatched kernel, each failing registration increased nr_foll_pin_acquired - nr_foll_pin_released by one. The faulty code is also present in current mainline, linux-next, the TEE maintainer's next branch, and the supported 7.2.y, 7.1.y, 6.18.y, and 6.12.y branches. Regards, Shukai Shukai Ni (1): tee: fix page count in register_shm_helper() error path drivers/tee/tee_shm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: cee9395acd8043be0644b25c34bfa86623f2b935 -- 2.55.0

1 month, 1 week

1
1
0 0

[PATCH v4 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation

by Jorge Ramirez-Ortiz

This series makes UFS RPMB work out of the box with an OP-TEE that implements the standard eMMC RPMB key-derivation flow, without requiring any fundamental changes on the OP-TEE side. RPMB provides an authenticated, replay-protected storage area whose security relies on a secret authentication key. In our setup that key is never exposed to the kernel: OP-TEE derives it in the secure world from its hardware-unique key and a device identifier (dev_id) that the RPMB core hands down. OP-TEE's implementation targets eMMC, where dev_id is the 16-byte eMMC CID, and both the fixed length and the raw-CID layout are baked into its key derivation. Two things stand in the way of reusing that same, unmodified OP-TEE flow for UFS RPMB: 1. On a cold boot the very first frame sent to the RPMB well-known LU comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI core reports rather than retries. RPMB has no earlier guaranteed access that could clear the condition first, so RPMB fails on every power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT ATTENTION on the RPMB WLUN. 2. The UFS RPMB id is "<device_id>-R<region>", which is variable length and longer than 16 bytes. Passing it verbatim would tie the derived key to a length OP-TEE does not expect and diverge from the fixed eMMC CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with blake2b, keeping the key stable and unique per region while matching the eMMC CID layout OP-TEE relies on. The hash algorithm and input string are thus part of the key-derivation ABI and must stay stable. With both patches, UFS RPMB is functional from the first access after a cold boot and derives keys through the existing eMMC-style OP-TEE flow, (requires minimal OP-TEE changes pending on the CID proposal done here). Tested on IQ-9075 with Open Firmware [1], pending OP-TEE changes [1]https://ldts.github.io/qcom-buildroot Dependencies: U-boot: https://lore.kernel.org/u-boot/20260720085202.537019-1-jorge.ramirez@oss.qu… OP-TEE: https://github.com/OP-TEE/optee_os/pull/7881 v4: * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN: open-code the power-on ASC 0x29 (with a naming comment) as the rest of the SCSI tree does, instead of a UFS_RPMB_ASC_POWER_ON define; add a UFS_RPMB_UA_RETRIES define for the retry count; reworded the commit message. * ufs: rpmb: use a fixed-length RPMB dev_id: reworded the commit message; no functional change. v3: * ufs: rpmb: use a fixed-length RPMB dev_id: hash into a stack buffer instead of a kzalloc'd one; rpmb_dev_register() copies dev_id, so the heap allocation and its cleanup were unnecessary. v2: * ufs: rpmb: replace blake2s with blake2b so that the same support can be added to u-boot (CRYPTO_LIB_BLAKE2B) * added links to U-boot and OP-TEE changes. v1: * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN: - fix using uses SCMD_FAILURE_ASC_ANY to retry any Unit Attention - fix unused variable * ufs: rpmb: use a fixed-length RPMB dev_id - fix selecting a non-existent Kconfig symbol Jorge Ramirez-Ortiz (2): ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN ufs: rpmb: use a fixed-length RPMB dev_id drivers/ufs/Kconfig | 1 + drivers/ufs/core/ufs-rpmb.c | 29 ++++++++++++++++++++++++++--- 2 files changed, 27 insertions(+), 3 deletions(-) -- 2.54.0

1 month, 1 week

3
6
0 0

[PATCH v3 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation

by Jorge Ramirez-Ortiz

This series makes UFS RPMB work out of the box with an OP-TEE that implements the standard eMMC RPMB key-derivation flow, without requiring any fundamental changes on the OP-TEE side. RPMB provides an authenticated, replay-protected storage area whose security relies on a secret authentication key. In our setup that key is never exposed to the kernel: OP-TEE derives it in the secure world from its hardware-unique key and a device identifier (dev_id) that the RPMB core hands down. OP-TEE's implementation targets eMMC, where dev_id is the 16-byte eMMC CID, and both the fixed length and the raw-CID layout are baked into its key derivation. Two things stand in the way of reusing that same, unmodified OP-TEE flow for UFS RPMB: 1. On a cold boot the very first frame sent to the RPMB well-known LU comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI core reports rather than retries. RPMB has no earlier guaranteed access that could clear the condition first, so RPMB fails on every power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT ATTENTION on the RPMB WLUN. 2. The UFS RPMB id is "<device_id>-R<region>", which is variable length and longer than 16 bytes. Passing it verbatim would tie the derived key to a length OP-TEE does not expect and diverge from the fixed eMMC CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with blake2b, keeping the key stable and unique per region while matching the eMMC CID layout OP-TEE relies on. The hash algorithm and input string are thus part of the key-derivation ABI and must stay stable. With both patches, UFS RPMB is functional from the first access after a cold boot and derives keys through the existing eMMC-style OP-TEE flow, (requires minimal OP-TEE changes pending on the CID proposal done here). Tested on IQ-9075 with Open Firmware [1], pending OP-TEE changes [1]https://ldts.github.io/qcom-buildroot Dependencies: U-boot: https://lore.kernel.org/u-boot/20260720085202.537019-1-jorge.ramirez@oss.qu… OP-TEE: https://github.com/OP-TEE/optee_os/pull/7881 v3: * ufs: rpmb: use a fixed-length RPMB dev_id: hash into a stack buffer instead of a kzalloc'd one; rpmb_dev_register() copies dev_id, so the heap allocation and its cleanup were unnecessary. v2: * ufs: rpmb: replace blake2s with blake2b so that the same support can be added to u-boot (CRYPTO_LIB_BLAKE2B) * added links to U-boot and OP-TEE changes. v1: * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN: - fix using uses SCMD_FAILURE_ASC_ANY to retry any Unit Attention - fix unused variable * ufs: rpmb: use a fixed-length RPMB dev_id - fix selecting a non-existent Kconfig symbol Jorge Ramirez-Ortiz (2): ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN ufs: rpmb: use a fixed-length RPMB dev_id drivers/ufs/Kconfig | 1 + drivers/ufs/core/ufs-rpmb.c | 29 ++++++++++++++++++++++++++--- 2 files changed, 27 insertions(+), 3 deletions(-) -- 2.54.0

1 month, 1 week

3
5
0 0

[PATCH v2] tee: qcomtee: fix kernel-doc warnings

by Babanpreet Singh

Fix kernel-doc issues present since the driver was added in commit d6e290837e50 ("tee: add Qualcomm TEE driver"): - async_release() documents its second parameter as @msg, but the parameter is named async_msg (msg is a local variable); - struct qcomtee_msg_object_invoke documents member @ctx, but the member is named cxt; - enum qcomtee_arg_type leaves QCOMTEE_ARG_TYPE_NR undescribed. The cxt spelling is part of the QTEE message format and is used throughout the driver; struct qcomtee_msg_callback in the same header already documents it as @cxt, so the comment is corrected rather than the member. No functional changes. Fixes: d6e290837e50 ("tee: add Qualcomm TEE driver") Reviewed-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> Assisted-by: Claude:claude-opus-5 [kernel-doc] Signed-off-by: Babanpreet Singh <bbnpreetsingh(a)gmail.com> --- v2: - add the Fixes tag Jens asked for; no code changes - pick up Amirreza's Reviewed-by v1: https://lore.kernel.org/all/20260802003956.7-1-bbnpreetsingh@gmail.com/ drivers/tee/qcomtee/async.c | 4 ++-- drivers/tee/qcomtee/qcomtee_msg.h | 2 +- drivers/tee/qcomtee/qcomtee_object.h | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/tee/qcomtee/async.c b/drivers/tee/qcomtee/async.c index 31bff4309e672..5849e51612033 100644 --- a/drivers/tee/qcomtee/async.c +++ b/drivers/tee/qcomtee/async.c @@ -97,10 +97,10 @@ static void qcomtee_get_async_buffer(struct qcomtee_object_invoke_ctx *oic, /** * async_release() - Process QTEE async release requests. * @oic: context used for the current invocation. - * @msg: async message for object release. + * @async_msg: async message for object release. * @size: size of the async buffer available. * - * Return: Size of the outbound buffer used when processing @msg. + * Return: Size of the outbound buffer used when processing @async_msg. */ static size_t async_release(struct qcomtee_object_invoke_ctx *oic, struct qcomtee_async_msg_hdr *async_msg, diff --git a/drivers/tee/qcomtee/qcomtee_msg.h b/drivers/tee/qcomtee/qcomtee_msg.h index 878f70178a5b6..5d7b21fdd3688 100644 --- a/drivers/tee/qcomtee/qcomtee_msg.h +++ b/drivers/tee/qcomtee/qcomtee_msg.h @@ -112,7 +112,7 @@ union qcomtee_msg_arg { /** * struct qcomtee_msg_object_invoke - Direct object invocation message. - * @ctx: object ID hosted in QTEE. + * @cxt: object ID hosted in QTEE. * @op: operation for the object. * @counts: number of different types of arguments in @args. * @args: array of arguments. diff --git a/drivers/tee/qcomtee/qcomtee_object.h b/drivers/tee/qcomtee/qcomtee_object.h index 8b4401ecad48c..d5de02dcef3b9 100644 --- a/drivers/tee/qcomtee/qcomtee_object.h +++ b/drivers/tee/qcomtee/qcomtee_object.h @@ -74,6 +74,7 @@ enum qcomtee_object_type { * @QCOMTEE_ARG_TYPE_OO: output object (OO). * @QCOMTEE_ARG_TYPE_IB: input buffer (IB). * @QCOMTEE_ARG_TYPE_IO: input object (IO). + * @QCOMTEE_ARG_TYPE_NR: number of argument types. * * Use the invalid type to specify the end of the argument array. */ base-commit: 2d2338c93da79b3bfe4b6099a931d9468d539952 -- 2.43.0

1 month, 2 weeks

2
1
0 0

OP-TEE Contributions Forum, monthly meeting August 24

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/ Following up on some points from the last meeting: The OP-TEE 4.11.0 release is planned for October 16. We skipped the July 17 release earlier, so this release will be a bit larger than usual. During the last meeting, we discussed giving Etienne merge rights. He's already part of "THE REST" in the MAINTAINERS file, so this makes a lot of sense. It's also good to see how we can staff during holiday seasons. It would also be nice to have more people in "THE CORE REVIEWERS". Help reviewing vulnerability reports and their fixes is most welcome. We should probably take this offline. If someone can help review or even draft fixes, please drop me a note, and we'll figure out how to work together. Any other topics? Cheers, Jens

1 month, 2 weeks

2
1
0 0

[PATCH v4 0/3] tee: add MbedTEE driver

by Xing Loong

This series adds a Linux TEE driver for MbedTEE, a Trusted Execution Environment for embedded systems (https://github.com/mbedtee). Two RPC transports are provided for systems where platform firmware or board configuration has already established the REE/TEE separation before Linux boots: - ARM/ARM64: SMC calls and GIC SPI notifications (TrustZone) - RISC-V: shared-memory ring buffers and IMSIC MSI notifications The driver implements the TEE subsystem interface (tee_driver_ops) and provides GlobalPlatform TEE Client API support, dynamic shared memory registration, and tee-supplicant support for REE filesystem and RPMB operations. The series is structured as follows: [1/3] dt-bindings: vendor-prefixes: add mbedtee [2/3] dt-bindings: firmware: add mbedtee,tee binding [3/3] tee: add MbedTEE driver --- Changes in v4: - 0002: Move reserved-memory region descriptions into memory-region-names property (Rob) - 0002: Define memory-region-names item order at top level; keep per-branch name count constraints (maxItems: 2 / minItems: 3) (Rob) - 0003: Harden ring and RPC handling against malformed input: - Validate both ring indices; bound async ring skip and resync the reader on corrupt framing - Enforce RPC handler modes (COMPLETE_REE async-only, supplicant commands sync-only) - Reference-count rpc_call objects; fix use-after-free on interrupted calls; abort and free leftover calls at teardown - Add XA_FLAGS_LOCK_IRQ to the rpc_calls xarray - Fix supp_recv/supp_abort_all race; malformed supp_send unblocks the worker instead of hanging it - Reject TEE-changed parameter attributes - Report the wire error on failed supplicant requests; fail oversized requests instead of requeueing them forever - Wait for R2T ring space with a bounded backoff; bound COMPLETE_TEE retries and stop them at teardown - Match the supplicant context when dispatching supp_send - Access complete_work_pending under ring_lock - Serialize RPC submission against shutdown and reject new calls once teardown starts - Quiesce all RPC activity before tee_device_unregister() so parked waiters cannot deadlock teardown - Bound non-interruptible RISC-V waits so a hung TEE cannot block ioctls forever - Track closing state on sessions; reject concurrent close/invoke/cancel races - Quarantine TEE-owned call objects at release instead of risking a cross-world use-after-free - Link to v3: https://lore.kernel.org/r/20260720073558.799755-1-xing.xl.loong@gmail.com/ Changes in v3: - 0002: Drop all phandle stub nodes from examples. - 0002: Remove redundant required: - interrupts from then branch. - 0002: Simplify title and description. - Link to v2: https://lore.kernel.org/r/20260702151115.544016-1-xing.xl.loong@gmail.com/ - Link to v1: https://lore.kernel.org/r/20260701132514.186953-1-xing.xl.loong@gmail.com/ Changes in v2: - 0002: Fix DT binding review comments from Krzysztof Kozlowski: - Drop $nodename, "YAML devicetree binding" wording, property descriptions - Rename compatible string to mbedtee,tee - Rename memory regions: rpc-t2r-ring -> t2r-ring, rpc-t2r-shm -> t2r-shm, rpc-r2t-ring -> r2t-ring - Add memory-region / memory-region-names to required - Simplify allOf constraints (drop redundant else-branch items) - Rewrite description to describe hardware/firmware, not the binding or driver - Drop all irrelevant platform nodes (gic, cpus, reserved-memory) - Add maxItems: 1 constraint to interrupts property (Sashiko AI review) - 0003: - Fix supp_release incorrectly aborting unclaimed requests on close - Fix potential tee_shm double-free on supp_recv error path - Fix async RPC ring skip leaving orphaned payload bytes - Fix COMPLETE_TEE retry to also handle transient -ENOMEM on RISC-V - Fix session leak on close_session allocation failure: release kernel resources before sending RPC --- Xing Loong (3): dt-bindings: vendor-prefixes: add mbedtee dt-bindings: firmware: add mbedtee,tee binding tee: add MbedTEE driver .../bindings/firmware/mbedtee,tee.yaml | 102 +++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + Documentation/tee/index.rst | 1 + Documentation/tee/mbedtee.rst | 155 ++++ MAINTAINERS | 9 + drivers/tee/Kconfig | 3 +- drivers/tee/Makefile | 1 + drivers/tee/mbedtee/Kconfig | 20 + drivers/tee/mbedtee/Makefile | 11 + drivers/tee/mbedtee/core.c | 260 +++++++ drivers/tee/mbedtee/mbedtee_drv.h | 289 ++++++++ drivers/tee/mbedtee/mbedtee_msg.h | 219 ++++++ drivers/tee/mbedtee/rpc_callee.c | 697 ++++++++++++++++++ drivers/tee/mbedtee/rpc_callee_arm.c | 91 +++ drivers/tee/mbedtee/rpc_callee_riscv.c | 203 +++++ drivers/tee/mbedtee/rpc_caller.c | 697 ++++++++++++++++++ drivers/tee/mbedtee/rpc_caller_arm.c | 70 ++ drivers/tee/mbedtee/rpc_caller_riscv.c | 238 ++++++ drivers/tee/mbedtee/shm_pool.c | 105 +++ drivers/tee/mbedtee/shm_pool.h | 15 + drivers/tee/mbedtee/supp.c | 311 ++++++++ include/uapi/linux/tee.h | 1 + 22 files changed, 3499 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/firmware/mbedtee,tee.yaml create mode 100644 Documentation/tee/mbedtee.rst create mode 100644 drivers/tee/mbedtee/Kconfig create mode 100644 drivers/tee/mbedtee/Makefile create mode 100644 drivers/tee/mbedtee/core.c create mode 100644 drivers/tee/mbedtee/mbedtee_drv.h create mode 100644 drivers/tee/mbedtee/mbedtee_msg.h create mode 100644 drivers/tee/mbedtee/rpc_callee.c create mode 100644 drivers/tee/mbedtee/rpc_callee_arm.c create mode 100644 drivers/tee/mbedtee/rpc_callee_riscv.c create mode 100644 drivers/tee/mbedtee/rpc_caller.c create mode 100644 drivers/tee/mbedtee/rpc_caller_arm.c create mode 100644 drivers/tee/mbedtee/rpc_caller_riscv.c create mode 100644 drivers/tee/mbedtee/shm_pool.c create mode 100644 drivers/tee/mbedtee/shm_pool.h create mode 100644 drivers/tee/mbedtee/supp.c base-commit: 03e2778d1f11de9260543f969e9e888a1c2bf830 -- 2.43.0

1 month, 2 weeks

2
5
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE