- OP-TEE - lists.trustedfirmware.org

[PATCH RFC 0/5] tee: optee: add RISC-V RPMI TEE transport

by Amirreza Zarrabi

This RFC adds initial support for communicating with OP-TEE on RISC-V using the RPMI TEE service group [1] over the SBI MPXY [2] mailbox framework. The intention is to provide a transport for RISC-V systems similar in purpose to the FF-A transport currently used by OP-TEE on Arm systems. Linux and OP-TEE act as endpoints of the RPMI TEE service group, while the RPMI framework in machine-mode firmware mediates communication between them. The implementation closely follows the existing OP-TEE FF-A backend in drivers/tee/optee/ffa_abi.c. Where possible, the same overall design and lifetime rules are preserved, with FF-A operations mapped to equivalent RPMI TEE services. For shared memory, FF-A memory handles are replaced by RPMI memory parcel identifiers. Linux creates an RPMI memory parcel for shared memory and makes OP-TEE a receiver of that parcel. The parcel identifier is then used in OP-TEE message parameters in a similar way to the FF-A global memory handle. RPMI TEE_CALL is used as the entry mechanism into OP-TEE, serving a role similar to the FF-A direct-message path. The request and response contain a small register-like payload carrying the OP-TEE call information and state required to resume yielding calls. The existing OP-TEE call queue, RPC handling and shared-memory infrastructure are reused as much as possible. The transport uses one SBI MPXY mailbox channel per hart. A TEE call is issued using the channel corresponding to the CPU on which the call is running. This preserves the execution model where entering OP-TEE on a hart results in secure-world execution associated with that hart. Shared memory is implemented using RPMI TEE memory parcels. The driver maintains a mapping between parcel identifiers and struct tee_shm objects and uses parcel create and reclaim operations to manage the lifetime of memory shared with OP-TEE. Asynchronous notifications are implemented using the RPMI TEE signal bus. The RPMI TEE service group does not provide framework notification events corresponding directly to the OP-TEE asynchronous notification mechanism, so the signal bus is used to carry notification values from OP-TEE to Linux. This is an early RFC and the implementation is not complete. There may still be functional bugs, incorrect assumptions, missing pieces, or interfaces that need to change. The series is being posted at this stage primarily to get feedback on the overall architecture and on how the OP-TEE ABI is mapped onto the RPMI TEE service group. The implementation deliberately follows the FF-A backend and ffa_abi.c closely. This allows the existing OP-TEE driver design to be reused and keeps the RISC-V and FF-A transports as consistent as possible. Some of these abstractions may need to be adjusted where the RPMI execution, notification, or memory model differs from FF-A, while others may eventually be shared between the transports. [1] https://github.com/riscv-non-isa/riscv-rpmi/commits/main/src/srvgrp-tee.adoc [2] https://github.com/riscv-non-isa/riscv-sbi-doc/releases Signed-off-by: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> --- Amirreza Zarrabi (5): optee: riscv: add RPMI TEE service group transport optee: riscv: add shared memory and scheduled calls optee: riscv: enable persistent shared argument cache optee: riscv: add asynchronous notifications over the signal bus dt-bindings: tee: add RISC-V RPMI TEE transport .../bindings/tee/riscv,rpmi-mpxy-tee.yaml | 65 + MAINTAINERS | 1 + drivers/tee/optee/Makefile | 1 + drivers/tee/optee/core.c | 8 +- drivers/tee/optee/optee_private.h | 47 + drivers/tee/optee/optee_riscv.c | 1621 ++++++++++++++++++++ drivers/tee/optee/optee_riscv.h | 334 ++++ include/linux/mailbox/riscv-rpmi-message.h | 1 + 8 files changed, 2076 insertions(+), 2 deletions(-) --- base-commit: 68142f986ff04b2b70b31db00f719bf690f64a9a change-id: 20260912-rpmi-tee-service-grp-dev-b2ce2f63e0df Best regards, -- Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com>

1 hour, 25 minutes

4
13
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>

14 hours, 7 minutes

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

19 hours, 35 minutes

2
4
0 0

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

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

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

1 day, 12 hours

4
3
0 0

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

by Kuldeep Singh

Qualcomm platforms with a discrete TPM (dTPM) talked to it directly over a non-secure SPI channel from the kernel. Arm's Base Boot Security Requirements (BBSR) v1.4 require that access to go through TrustZone instead, so on affected Qualcomm platforms the TPM 2.0 instance is now fronted by a Trusted Application (TA) running inside Qualcomm's Trusted Execution Environment (QTEE), which talks to the dTPM (or implements an fTPM) on the kernel's behalf. This series adds a kernel driver for that TA, built on the QCOMTEE object-IPC transport (drivers/tee/qcomtee/) already used to reach other QTEE services. This patch series functionally depends on below(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> --- Changes in v2: - Use QCOMTEE_TPM_UID as 81 for service discovery in patch 1. - Use FIELD_GET, zero initialised array and log improvement (Konrad) - Improve commit title and other fixes (Jarkko) - Split MAINTAINERS entry as separate patch. - Link to v1: https://patch.msgid.link/20260831-tpm_qcom_driver-v1-0-6f16fa6924fa@oss.qua… To: Amirreza Zarrabi <amirreza.zarrabi(a)oss.qualcomm.com> To: Jens Wiklander <jenswi(a)kernel.org> To: Sumit Garg <sumit.garg(a)kernel.org> To: Peter Huewe <peterhuewe(a)gmx.de> To: Jarkko Sakkinen <jarkko(a)kernel.org> To: Jason Gunthorpe <jgg(a)ziepe.ca> To: Kuldeep Singh <kuldeep.singh(a)oss.qualcomm.com> Cc: linux-arm-msm(a)vger.kernel.org Cc: op-tee(a)lists.trustedfirmware.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-integrity(a)vger.kernel.org --- Kuldeep Singh (3): tee: qcomtee: Register qcom.tz.tpm service for discovery tpm: Introduce Qualcomm TPM driver MAINTAINERS: Add Qualcomm TPM driver entry MAINTAINERS | 7 + drivers/char/tpm/Kconfig | 9 + drivers/char/tpm/Makefile | 1 + drivers/char/tpm/tpm_qcom.c | 354 ++++++++++++++++++++++++++++++++++++++ drivers/char/tpm/tpm_qcom.h | 83 +++++++++ drivers/tee/qcomtee/call.c | 4 +- drivers/tee/qcomtee/qcomtee_msg.h | 2 + 7 files changed, 459 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>

1 day, 13 hours

1
4
0 0

[PATCH] tee: move tee_ioctl_shm_register_data to above IOCTL definition

by Andrew Davis

Most of the struct definitions for a given IOCTL definition immediately preceded that definition. The struct tee_ioctl_shm_register_data is an exception as it is placed above the TEE_IOC_SHM_REGISTER_FD definition, not the TEE_IOC_SHM_REGISTER one it is to be used with. Move it down to match the others. This is a non-functional change for consistency and to help prevent someone from accidentally using the wrong struct with the wrong IOCTL based on the struct's location. Fix a couple small spelling issues while here. Signed-off-by: Andrew Davis <afd(a)ti.com> --- include/uapi/linux/tee.h | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h index 5203977ed35d1..76815b0f4b665 100644 --- a/include/uapi/linux/tee.h +++ b/include/uapi/linux/tee.h @@ -384,24 +384,6 @@ struct tee_iocl_supp_send_arg { #define TEE_IOC_SUPPL_SEND _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 7, \ struct tee_ioctl_buf_data) -/** - * struct tee_ioctl_shm_register_data - Shared memory register argument - * @addr: [in] Start address of shared memory to register - * @length: [in/out] Length of shared memory to register - * @flags: [in/out] Flags to/from registration. - * @id: [out] Identifier of the shared memory - * - * The flags field should currently be zero as input. Updated by the call - * with actual flags as defined by TEE_IOCTL_SHM_* above. - * This structure is used as argument for TEE_IOC_SHM_REGISTER below. - */ -struct tee_ioctl_shm_register_data { - __u64 addr; - __u64 length; - __u32 flags; - __s32 id; -}; - /** * struct tee_ioctl_shm_register_fd_data - Shared memory registering argument * @fd: [in] File descriptor identifying dmabuf reference @@ -426,13 +408,31 @@ struct tee_ioctl_shm_register_fd_data { * Returns a file descriptor on success or < 0 on failure * * The returned file descriptor refers to the shared memory object in the - * kernel. The supplied file deccriptor can be closed if it's not needed + * kernel. The supplied file descriptor can be closed if it's not needed * for other purposes. The shared memory is freed when the descriptor is * closed. */ #define TEE_IOC_SHM_REGISTER_FD _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 8, \ struct tee_ioctl_shm_register_fd_data) +/** + * struct tee_ioctl_shm_register_data - Shared memory register argument + * @addr: [in] Start address of shared memory to register + * @length: [in/out] Length of shared memory to register + * @flags: [in/out] Flags to/from registration. + * @id: [out] Identifier of the shared memory + * + * The flags field should currently be zero as input. Updated by the call + * with actual flags as defined by TEE_IOCTL_SHM_* above. + * This structure is used as argument for TEE_IOC_SHM_REGISTER below. + */ +struct tee_ioctl_shm_register_data { + __u64 addr; + __u64 length; + __u32 flags; + __s32 id; +}; + /** * TEE_IOC_SHM_REGISTER - Register shared memory argument * @@ -440,7 +440,7 @@ struct tee_ioctl_shm_register_fd_data { * * Returns a file descriptor on success or < 0 on failure * - * The shared memory is unregisterred when the descriptor is closed. + * The shared memory is unregistered when the descriptor is closed. */ #define TEE_IOC_SHM_REGISTER _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 9, \ struct tee_ioctl_shm_register_data) -- 2.39.2

1 day, 13 hours

3
3
0 0

[PATCH 0/3] tee: optee: prepare the driver for RISC-V

by marouene.boubakri＠oss.nxp.com

From: Marouene Boubakri <marouene.boubakri(a)oss.nxp.com> The OP-TEE driver reaches OP-TEE through the SMC ABI or the FF-A ABI, both specific to Arm, and the TEE subsystem and the OP-TEE driver depend on HAVE_ARM_SMCCC. On RISC-V there is no SMC instruction: OP-TEE runs in a domain isolated by the M-mode firmware and is reached through the RISC-V Platform Management Interface (RPMI), carried on an SBI Message Proxy (MPXY) channel, for which Linux already has a mailbox driver. This series only puts the build plumbing in place for a third ABI next to the SMC and FF-A ones: - patch 1 builds the Arm-specific code of the driver only on Arm: smc_abi.c when HAVE_ARM_SMCCC is set and ffa_abi.c when ARM_FFA_TRANSPORT is enabled, with stubs for their registration otherwise. The SMCCC header, the SMC and FF-A specific types and the SMC RPC register parameters in optee_private.h are kept under the same conditions, so that nothing Arm-specific is left in the common part of the driver; - patch 2 adds an RPMI ABI placeholder: an OPTEE_RPMI_ABI option built when the MPXY mailbox driver is enabled, rpmi_abi.c and its registration from the driver core. The transport is not implemented, so the registration fails with -EOPNOTSUPP; - patch 3 lets the TEE subsystem and the OP-TEE driver be enabled on RISC-V, and teaches the memory type check of the driver about the RISC-V page attributes, without which the driver does not build there. It is kept separate as it changes the dependencies of the subsystem-wide TEE menu. There is no functional change. On Arm, OPTEE still depends on HAVE_ARM_SMCCC and the SMC and FF-A ABIs are built whenever they can be registered. On RISC-V the driver builds without any Arm-specific code but no ABI registers, so it does not load. The RPMI transport will be implemented on top of this in a separate series. Testing: [TODO before posting: riscv64 defconfig plus TEE/OP-TEE, built-in and as modules, and arm64 defconfig plus OP-TEE with FF-A built-in, modular and disabled, with W=1 at every step of the series.] Marouene Boubakri (3): tee: optee: build the Arm-specific code only on Arm tee: optee: add an RPMI ABI placeholder tee: optee: allow enabling the driver on RISC-V drivers/tee/Kconfig | 2 +- drivers/tee/optee/Kconfig | 10 +++++- drivers/tee/optee/Makefile | 5 +-- drivers/tee/optee/call.c | 8 +++++ drivers/tee/optee/core.c | 8 +++-- drivers/tee/optee/notif.c | 1 - drivers/tee/optee/optee_private.h | 52 ++++++++++++++++++++++++++++++- drivers/tee/optee/rpmi_abi.c | 23 ++++++++++++++ 8 files changed, 101 insertions(+), 8 deletions(-) create mode 100644 drivers/tee/optee/rpmi_abi.c base-commit: 827751b699b79a6e569983359c02dce67f81b94c -- 2.43.0

2 days, 20 hours

1
7
0 0

[PATCH 0/3] firmware: qcom: scm: pass struct qcom_scm through the API

by Albert Esteve

The SCM driver still funnels every call through a process-wide __scm singleton. This series threads struct qcom_scm through the driver and the exported API, then drops the global. Series summary -------------- Patch 1: Internal helpers take the instance. Callbacks that only have a struct device or reset_controller_dev recover it with drvdata / container_of. Exported signatures stay unchanged so this patch is bisectable on its own. Patch 2: Exported calls take struct qcom_scm * as the first argument. The type stays opaque in qcom_scm.h. Children of the SCM device (qseecom, tzmem, qcomtee) use dev_get_drvdata() on the parent. Other consumers call qcom_scm_get(), which finds the bound platform device and returns NULL until probe has marked the instance ready. Callers that need SCM return -EPROBE_DEFER; callers that only use it for an optional path (rmtfs VMIDs, fastrpc vmids, PAS region assign, Venus CP, HDMI HDCP, Adreno fuse poke) skip the lookup or tolerate NULL. qcom_pas_* is unchanged: PAS has a TEE backend, so those ops keep struct device * and the SCM backend uses drvdata. Patch 3: Drop __scm. Readiness is scm->available with the same release/acquire pairing as today. Module-parameter stores reuse qcom_scm_get(); shutdown uses platform_get_drvdata(). No intended change in SCM calling convention or wait-queue behaviour. Testing ------- Booted to a shell on Qualcomm SA8775P Ride4 with current series. qcom_scm bound as firmware:qcom_scm; probe logged SMC ARM 64 and the tz-ffi reserved-memory assignment. Consumers were not exercised. Suggested-by: Maxime Ripard <mripard(a)kernel.org> Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Albert Esteve (3): firmware: qcom: scm: pass qcom_scm to internal helpers firmware: qcom: scm: pass qcom_scm through the exported API firmware: qcom: scm: drop the __scm global arch/arm/mach-qcom/platsmp.c | 3 +- drivers/cpuidle/cpuidle-qcom-spm.c | 28 +- drivers/firmware/qcom/qcom_qseecom.c | 3 +- drivers/firmware/qcom/qcom_scm-smc.c | 2 +- drivers/firmware/qcom/qcom_scm.c | 518 +++++++++++++---------- drivers/firmware/qcom/qcom_scm.h | 2 +- drivers/firmware/qcom/qcom_tzmem.c | 6 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +- drivers/gpu/drm/msm/hdmi/hdmi_hdcp.c | 6 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 9 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 8 +- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.h | 3 + drivers/iommu/arm/arm-smmu/qcom_iommu.c | 18 +- drivers/irqchip/qcom-pdc.c | 6 +- drivers/media/platform/qcom/venus/firmware.c | 10 +- drivers/misc/fastrpc.c | 31 +- drivers/net/wireless/ath/ath10k/qmi.c | 12 +- drivers/net/wireless/ath/ath10k/qmi.h | 3 + drivers/nvmem/sec-qfprom.c | 6 +- drivers/pinctrl/qcom/pinctrl-msm.c | 11 +- drivers/remoteproc/qcom_q6v5_mss.c | 6 +- drivers/remoteproc/qcom_q6v5_pas.c | 12 +- drivers/soc/qcom/ice.c | 23 +- drivers/soc/qcom/ocmem.c | 22 +- drivers/soc/qcom/rmtfs_mem.c | 8 +- drivers/tee/qcomtee/call.c | 7 + drivers/tee/qcomtee/core.c | 6 +- drivers/tee/qcomtee/qcomtee.h | 2 + drivers/thermal/qcom/lmh.c | 22 +- include/linux/firmware/qcom/qcom_qseecom.h | 5 +- include/linux/firmware/qcom/qcom_scm.h | 117 ++--- 32 files changed, 566 insertions(+), 363 deletions(-) --- base-commit: bc35965f6940a9bf834d54187b6088b8eb09206d change-id: 20260908-scm-device-api-634ac7a7f377 Best regards, -- Albert Esteve <aesteve(a)redhat.com>

3 days, 9 hours

1
3
0 0

[PATCH] tee: optee: ffa: support shared memory offsets on large-page kernels

by Mahantesh Salimath

OP-TEE FF-A memory objects use 4 KiB pages, while the kernel page size may be larger. Consequently, tee_shm->offset can be greater than or equal to FFA_PAGE_SIZE, but OP-TEE rejects such a value in internal_offs. Do not encode the excess page offset in offs_low/offs_high. Those fields describe the logical memref offset and are copied back into tee_param->shm_offs on return. Folding the page offset into them breaks parameter round trips when a memref is reused. They are also ignored by the OPTEE_RPC_CMD_SHM_ALLOC response path, which uses only global_id and internal_offs to construct the shared-memory mobj. Instead, start the FF-A descriptor at the 4 KiB page containing the shared buffer, the same approach as optee_fill_pages_list() in the SMC ABI. Store the remaining in-page offset in internal_offs and preserve shm_offs in offs_low/offs_high. This keeps internal_offs within the FF-A page size, maps RPC allocations at the correct address, and preserves normal memref offsets across repeated invocations. Tested on ARMv8-A with 64 KiB PAGE_SIZE. OP-TEE OS ran as a secure partition under Hafnium (SPMC) over FF-A. Verified registered shared memory with tee_shm->offset >= 4 KiB, memref reuse on the same TEEC_Operation, and RPC OPTEE_RPC_CMD_SHM_ALLOC (xtest regression 6007-6009). optee_hello_world, optee_aes, and xtest regression 1005, 1007, 1008, 4001-4003 and 6001-6003 also passed. Fixes: 4615e5a34b95 ("optee: add FF-A support") Acked-by: Liming Sun <limings(a)nvidia.com> Acked-by: James Hurley <jahurley(a)nvidia.com> Acked-by: Dave Thompson <davthompson(a)nvidia.com> Signed-off-by: Mahantesh Salimath <mahantesh(a)nvidia.com> --- drivers/tee/optee/ffa_abi.c | 66 +++++++++++++++++++++++++++++------ drivers/tee/optee/optee_msg.h | 4 +-- 2 files changed, 57 insertions(+), 13 deletions(-) diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c index 633715b98625..2a37e4899dc6 100644 --- a/drivers/tee/optee/ffa_abi.c +++ b/drivers/tee/optee/ffa_abi.c @@ -187,6 +187,40 @@ static int optee_ffa_from_msg_param(struct optee *optee, return 0; } +/* + * OP-TEE FF-A memory objects use 4 KiB pages while the kernel page size may + * be larger, for example 64 KiB on arm64. The FF-A descriptor is registered + * from the 4 KiB page containing the start of the shared buffer, so + * internal_offs is the offset into that page. + */ +static void optee_ffa_set_internal_offs(struct optee_msg_param_fmem *fmem, + struct tee_shm *shm) +{ + size_t page_offs = tee_shm_get_page_offset(shm); + + BUILD_BUG_ON(PAGE_SIZE < FFA_PAGE_SIZE); + + fmem->internal_offs = page_offs & (FFA_PAGE_SIZE - 1); +} + +/* + * Keep shm_offs unchanged in offs_low/offs_high: it is returned to callers + * and may be reused for a subsequent invocation. + */ +static int optee_ffa_set_fmem_offsets(struct optee_msg_param_fmem *fmem, + struct tee_shm *shm, u64 shm_offs) +{ + optee_ffa_set_internal_offs(fmem, shm); + + fmem->offs_low = shm_offs; + fmem->offs_high = shm_offs >> 32; + /* Check that the entire offset could be stored. */ + if (fmem->offs_high != shm_offs >> 32) + return -EINVAL; + + return 0; +} + static int to_msg_param_ffa_mem(struct optee_msg_param *mp, const struct tee_param *p) { @@ -196,14 +230,8 @@ static int to_msg_param_ffa_mem(struct optee_msg_param *mp, TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT; if (shm) { - u64 shm_offs = p->u.memref.shm_offs; - - mp->u.fmem.internal_offs = shm->offset; - - mp->u.fmem.offs_low = shm_offs; - mp->u.fmem.offs_high = shm_offs >> 32; - /* Check that the entire offset could be stored. */ - if (mp->u.fmem.offs_high != shm_offs >> 32) + if (optee_ffa_set_fmem_offsets(&mp->u.fmem, shm, + p->u.memref.shm_offs)) return -EINVAL; mp->u.fmem.global_id = shm->sec_world_id; @@ -284,14 +312,30 @@ static int optee_ffa_shm_register(struct tee_context *ctx, struct tee_shm *shm, .nattrs = 1, }; struct sg_table sgt; + size_t page_offs; + size_t ffa_offs; + size_t ffa_size; int rc; + if (!num_pages) + return -EINVAL; + rc = optee_check_mem_type(start, num_pages); if (rc) return rc; - rc = sg_alloc_table_from_pages(&sgt, pages, num_pages, 0, - num_pages * PAGE_SIZE, GFP_KERNEL); + page_offs = tee_shm_get_page_offset(shm); + ffa_offs = round_down(page_offs, FFA_PAGE_SIZE); + ffa_size = num_pages * PAGE_SIZE - ffa_offs; + + /* + * Start the FF-A descriptor at the 4 KiB page containing the shared + * buffer, skipping unused leading 4 KiB pages when PAGE_SIZE is + * larger. Same approach as optee_fill_pages_list() in the SMC ABI. + * This leaves only page_offs & (FFA_PAGE_SIZE - 1) for internal_offs. + */ + rc = sg_alloc_table_from_pages(&sgt, pages, num_pages, ffa_offs, + ffa_size, GFP_KERNEL); if (rc) return rc; args.sg = sgt.sgl; @@ -458,8 +502,8 @@ static void handle_ffa_rpc_func_cmd_shm_alloc(struct tee_context *ctx, .attr = OPTEE_MSG_ATTR_TYPE_FMEM_OUTPUT, .u.fmem.size = tee_shm_get_size(shm), .u.fmem.global_id = shm->sec_world_id, - .u.fmem.internal_offs = shm->offset, }; + optee_ffa_set_internal_offs(&arg->params[0].u.fmem, shm); arg->ret = TEEC_SUCCESS; } diff --git a/drivers/tee/optee/optee_msg.h b/drivers/tee/optee/optee_msg.h index 7d9b12e71c03..6c3043f8da33 100644 --- a/drivers/tee/optee/optee_msg.h +++ b/drivers/tee/optee/optee_msg.h @@ -136,8 +136,8 @@ struct optee_msg_param_rmem { * struct optee_msg_param_fmem - FF-A memory reference parameter * @offs_low: lower bits of offset into shared memory reference * @offs_high: higher bits of offset into shared memory reference - * @internal_offs: internal offset into the first page of shared memory - * reference + * @internal_offs: offset into the first 4 KiB page of the FF-A shared + * memory region * @size: size of the buffer * @global_id: global identifier of the shared memory */ -- 2.43.0

1 week

2
3
0 0

[PATCH RESEND] tee: move tee_ioctl_shm_register_data to above IOCTL definition

by Andrew Davis

Most of the struct definitions for a given IOCTL definition immediately preceded that definition. The struct tee_ioctl_shm_register_data is an exception as it is placed above the TEE_IOC_SHM_REGISTER_FD definition, not the TEE_IOC_SHM_REGISTER one it is to be used with. Move it down to match the others. This is a non-functional change for consistency and to help prevent someone from accidentally using the wrong struct with the wrong IOCTL based on the struct's location. Fix a couple small spelling issues while here. Signed-off-by: Andrew Davis <afd(a)ti.com> --- Resending using folks updated emails :) include/uapi/linux/tee.h | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h index 5203977ed35d1..76815b0f4b665 100644 --- a/include/uapi/linux/tee.h +++ b/include/uapi/linux/tee.h @@ -384,24 +384,6 @@ struct tee_iocl_supp_send_arg { #define TEE_IOC_SUPPL_SEND _IOR(TEE_IOC_MAGIC, TEE_IOC_BASE + 7, \ struct tee_ioctl_buf_data) -/** - * struct tee_ioctl_shm_register_data - Shared memory register argument - * @addr: [in] Start address of shared memory to register - * @length: [in/out] Length of shared memory to register - * @flags: [in/out] Flags to/from registration. - * @id: [out] Identifier of the shared memory - * - * The flags field should currently be zero as input. Updated by the call - * with actual flags as defined by TEE_IOCTL_SHM_* above. - * This structure is used as argument for TEE_IOC_SHM_REGISTER below. - */ -struct tee_ioctl_shm_register_data { - __u64 addr; - __u64 length; - __u32 flags; - __s32 id; -}; - /** * struct tee_ioctl_shm_register_fd_data - Shared memory registering argument * @fd: [in] File descriptor identifying dmabuf reference @@ -426,13 +408,31 @@ struct tee_ioctl_shm_register_fd_data { * Returns a file descriptor on success or < 0 on failure * * The returned file descriptor refers to the shared memory object in the - * kernel. The supplied file deccriptor can be closed if it's not needed + * kernel. The supplied file descriptor can be closed if it's not needed * for other purposes. The shared memory is freed when the descriptor is * closed. */ #define TEE_IOC_SHM_REGISTER_FD _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 8, \ struct tee_ioctl_shm_register_fd_data) +/** + * struct tee_ioctl_shm_register_data - Shared memory register argument + * @addr: [in] Start address of shared memory to register + * @length: [in/out] Length of shared memory to register + * @flags: [in/out] Flags to/from registration. + * @id: [out] Identifier of the shared memory + * + * The flags field should currently be zero as input. Updated by the call + * with actual flags as defined by TEE_IOCTL_SHM_* above. + * This structure is used as argument for TEE_IOC_SHM_REGISTER below. + */ +struct tee_ioctl_shm_register_data { + __u64 addr; + __u64 length; + __u32 flags; + __s32 id; +}; + /** * TEE_IOC_SHM_REGISTER - Register shared memory argument * @@ -440,7 +440,7 @@ struct tee_ioctl_shm_register_fd_data { * * Returns a file descriptor on success or < 0 on failure * - * The shared memory is unregisterred when the descriptor is closed. + * The shared memory is unregistered when the descriptor is closed. */ #define TEE_IOC_SHM_REGISTER _IOWR(TEE_IOC_MAGIC, TEE_IOC_BASE + 9, \ struct tee_ioctl_shm_register_data) -- 2.39.2

1 week

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

OP-TEE