August 2026 - OP-TEE - lists.trustedfirmware.org

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

by Kuldeep Singh

Qualcomm platforms with a discrete TPM (dTPM) talked to it directly over a non-secure SPI channel from the kernel. Arm's Base Boot Security Requirements (BBSR) v1.4 require that access to go through TrustZone instead, so on affected Qualcomm platforms the TPM 2.0 instance is now fronted by a Trusted Application (TA) running inside Qualcomm's Trusted Execution Environment (QTEE), which talks to the dTPM (or implements an fTPM) on the kernel's behalf. This series adds a kernel driver for that TA, built on the QCOMTEE object-IPC transport (drivers/tee/qcomtee/) already used to reach other QTEE services. This patch series functionally depends on below(patch 5/6 specifically) for qtee service discovery. - https://lore.kernel.org/lkml/20260722-qcom_uefisecapp_migrate_qcomtee-v2-0-… Tested on Glymur-crd target with tpm2-tools utility. Validations: - Get capabilities - Random number generator - RSA key creation, encryption and decryption. Signed-off-by: Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com> --- Kuldeep Singh (2): tee: qcomtee: Register qcom.tz.tpm service for discovery firmware: tpm: Introduce tpm-qcom driver MAINTAINERS | 7 + drivers/char/tpm/Kconfig | 9 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_qcom.c | 371 ++++++++++++++++++++++++++++++++++++++ drivers/char/tpm/tpm_qcom.h | 82 +++++++++ drivers/tee/qcomtee/call.c | 4 +- drivers/tee/qcomtee/qcomtee_msg.h | 2 + 7 files changed, 475 insertions(+), 1 deletion(-) --- base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260831-tpm_qcom_driver-d21c720e73b2 prerequisite-change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014:v2 prerequisite-patch-id: 4dc81445c9baf36f420da8c2e2bed96e71b31a5b prerequisite-patch-id: b487dfe2fbc076f4815dc6c73b9e68b0b78c961f prerequisite-patch-id: c5df2b3696520a96f95b2d3535ed84cdc21cc315 prerequisite-patch-id: bbdd5327c15aeaa99ce9b74bab324a98f084ed48 prerequisite-patch-id: 07d9c4e9fe9fd61f60e3f35b30b9d81716f0734c prerequisite-patch-id: 10ff88d87586f21f3cff3f72dbd21c27adbfbbcc Best regards, -- Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com>

7 hours, 25 minutes

3
10
0 0

[PATCH v5 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 v5: * added Reviewed-by tags from Bean Huo and Stanley Jhu; no code change. 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

14 hours, 5 minutes

2
3
0 0

[PATCH v2 0/6] Add TEE based client driver for UEFI Secure Application

by Harshal Dev

On Qualcomm SoC based platforms, UEFI stores EFI variables within the Replay Protected Memory Block (RPMB) which is only accessible by the Qualcomm Trusted Execution Environment (QTEE). For Qualcomm platforms without emulated RPMB support, specifically platforms where RPMB is not located within SPI-NOR storage and instead located on UFS/EMMC storage, non-volatile EFI variables can only be set via a callback request from the UEFI Secure Application to the RPMB service running in user-space (within the QTEE supplicant [1]). Unlike the QCOM-TEE driver, the QSEECOM driver (used by the current QSEECOM based uefisecapp) does not support callback requests. And on certain Qualcomm platforms such as the RB3Gen2, attempts to access the QSEECOM interface fail due to lack of support within Qualcomm TEE. On these platforms, a TEE based uefisecapp client driver is required to: 1. Access cached & volatile EFI variables stored in uefisecapp's memory. 2. Ensure persistence of non-volatile EFI variables via writes through the RPMB service hosted in the QTEE supplicant. This series introduces such a uefisecapp TEE client driver for the aforementioned Qualcomm platforms which installs efi-var operations _if_ the QCOMTEE driver registers support for an object-IPC based uefisecapp service on the TEE bus during its probe. Only new QTEE firmware versions available at [2] provide this support. Thus, QCOMTEE now maintains a static list of always-available object-IPC based secure services exposed by QTEE. These services are implemented either within the QTEE kernel or within a pre-loaded Trusted Application (TA) usually loaded by the bootloader. The uefisecapp TA is an example of a preloaded TA loaded by UEFI. A static list is required since QTEE does not yet expose any way to dynamically query and enumerate the services exposed by it. To facilitate object-IPC interactions from the kernel-space, this series also introduces a tee_client_object_invoke_func() to allow invocation of TEE objects similar to the existing tee_client_invoke_func() API exported by the TEE subsystem which allows invocation of TEE functions. Some suporting changes are also introduced to track and handle operations for TEE contexts opened from the kernel-space in the back-end QCOM-TEE driver. Finally and as previously mentioned, access to the object-IPC based uefisecapp service is restricted on older QTEE firmware versions. A new QTEE firmware release must be picked up from QArtifactory [2] for all upstream supported Qualcomm SoCs to enable access to uefisecapp service via the TEE client driver. This patch series has been validated on Kodiak RB3Gen2 platform with UFS storage by attempting to read/write EFI variables via the efivar tool [3] after mounting the efivarfs filesystem. See [4] for an example. Merge Strategy: This patch series could either be taken from the OP-TEE tree or the QCOM soc tree. I would prefer it to be picked by the OP-TEE tree since all except the uefisecapp TEE client driver patch in this series make changes relevant to the TEE subsystem. It would be great if the QCOM soc tree maintainers can Ack the uefisecapp driver patch. [1] https://github.com/qualcomm/minkipc [2] https://shorturl.at/zQU07 [3] https://github.com/rhboot/efivar [4] https://docs.qualcomm.com/doc/80-70020-27/topic/manage_uefi_environment_var… Signed-off-by: Harshal Dev <harshal.dev(a)oss.qualcomm.com> --- Changes in v2: - Drop using MSB of the object_id to distingush kernel and user object invoke contexts. - Introduce enum tee_object_invoke_origin to check the context of object invocation. - Link to v1: https://lore.kernel.org/r/20260707-qcom_uefisecapp_migrate_qcomtee-v1-0-f65… --- Amirreza Zarrabi (2): tee: Add kernel client object invoke helper tee: qcomtee: Allow object invokes from kernel clients Harshal Dev (4): tee: qcomtee: Track the object invocation context tee: Export uuidv5 generation for TEE backends tee: qcomtee: Add support for registering QTEE services on TEE bus firmware: qcom: Add support for TEE based EFI-var client driver MAINTAINERS | 7 + drivers/firmware/qcom/Kconfig | 24 ++ drivers/firmware/qcom/Makefile | 1 + drivers/firmware/qcom/qcom_tee_uefisecapp.c | 525 ++++++++++++++++++++++++++++ drivers/firmware/qcom/qcom_tee_uefisecapp.h | 120 +++++++ drivers/tee/qcomtee/call.c | 205 ++++++++++- drivers/tee/qcomtee/core.c | 9 +- drivers/tee/qcomtee/qcomtee.h | 12 + drivers/tee/qcomtee/qcomtee_msg.h | 1 + drivers/tee/qcomtee/qcomtee_object.h | 16 +- drivers/tee/tee_core.c | 24 +- include/linux/tee_core.h | 23 +- include/linux/tee_drv.h | 18 +- 13 files changed, 952 insertions(+), 33 deletions(-) --- base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e change-id: 20260408-qcom_uefisecapp_migrate_qcomtee-13869d45e014 Best regards, -- Harshal Dev <harshal.dev(a)oss.qualcomm.com>

2 days, 6 hours

3
27
0 0

[PATCH v3] tee: remove TZMEM_MODE_GENERIC

by Julian Braha

'select' does not work on config options in a 'choice', so currently it is possible to enable QCOMTEE without QCOM_TZMEM_MODE_SHMBRIDGE, even though this is needed at runtime. There are no users of the generic allocator option, QCOM_TZMEM_MODE_GENERIC, so let's remove it. Then, we can remove the containing choice..endchoice, which allows the 'select' to work as intended. Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Julian Braha <julianbraha(a)gmail.com> --- Changes since v2: - add back stubs for when CONFIG_QCOM_TZMEM_MODE_GENERIC=n - updated help text accordingly Link: https://lore.kernel.org/all/20260729203845.387239-1-julianbraha@gmail.com/ Changes since v1: - remove TZMEM_MODE_GENERIC instead of removing the dead select Link: https://lore.kernel.org/all/20260715092539.18384-1-julianbraha@gmail.com/ --- drivers/firmware/qcom/Kconfig | 26 +++++--------------------- drivers/firmware/qcom/qcom_tzmem.c | 4 ++-- 2 files changed, 7 insertions(+), 23 deletions(-) diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig index c7f8413ab996..95b968d88dc3 100644 --- a/drivers/firmware/qcom/Kconfig +++ b/drivers/firmware/qcom/Kconfig @@ -34,33 +34,17 @@ config QCOM_TZMEM tristate select GENERIC_ALLOCATOR -choice - prompt "TrustZone interface memory allocator mode" - depends on QCOM_TZMEM - default QCOM_TZMEM_MODE_GENERIC - help - Selects the mode of the memory allocator providing memory buffers of - suitable format for sharing with the TrustZone. If in doubt, select - 'Generic'. - -config QCOM_TZMEM_MODE_GENERIC - bool "Generic" - help - Use the generic allocator mode. The memory is page-aligned, non-cachable - and physically contiguous. - config QCOM_TZMEM_MODE_SHMBRIDGE - bool "SHM Bridge" + bool "TrustZone interface memory allocator: SHM Bridge" + depends on QCOM_TZMEM help - Use Qualcomm Shared Memory Bridge. The memory has the same alignment as - in the 'Generic' allocator but is also explicitly marked as an SHM Bridge - buffer. + Use Qualcomm Shared Memory Bridge as memory allocator. The memory has the + same alignment as in the 'Generic' allocator, which is used when this option + is disabled, but is also explicitly marked as an SHM Bridge buffer. With this selected, all buffers passed to the TrustZone must be allocated using the TZMem allocator or else the TrustZone will refuse to use them. -endchoice - config QCOM_QSEECOM bool "Qualcomm QSEECOM interface driver" depends on QCOM_SCM=y diff --git a/drivers/firmware/qcom/qcom_tzmem.c b/drivers/firmware/qcom/qcom_tzmem.c index 0fd9581275f1..510474902c3a 100644 --- a/drivers/firmware/qcom/qcom_tzmem.c +++ b/drivers/firmware/qcom/qcom_tzmem.c @@ -50,7 +50,7 @@ static struct device *qcom_tzmem_dev; static RADIX_TREE(qcom_tzmem_chunks, GFP_ATOMIC); static DEFINE_SPINLOCK(qcom_tzmem_chunks_lock); -#if IS_ENABLED(CONFIG_QCOM_TZMEM_MODE_GENERIC) +#ifndef CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE static int qcom_tzmem_init(void) { @@ -67,7 +67,7 @@ static void qcom_tzmem_cleanup_area(struct qcom_tzmem_area *area) } -#elif IS_ENABLED(CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE) +#else #include <linux/firmware/qcom/qcom_scm.h> #include <linux/of.h> -- 2.55.0

1 week, 2 days

4
4
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 week, 2 days

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 week, 3 days

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 week, 3 days

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 week, 3 days

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

2 weeks

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

2 weeks, 3 days

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE August 2026