[PW_SID:1161681] tee: optee: RISC-V support over the RPMI TEE service group - #2633
Open
linux-riscv-bot wants to merge 6 commits into
Open
[PW_SID:1161681] tee: optee: RISC-V support over the RPMI TEE service group#2633linux-riscv-bot wants to merge 6 commits into
linux-riscv-bot wants to merge 6 commits into
Conversation
added 6 commits
September 10, 2026 01:22
…l requests An SBI MPXY message send is not queued in a hardware mailbox: it is an ecall executed on the calling hart with the calling hart's shared memory which returns once the SBI implementation has processed the message. For most RPMI service groups that means forwarding the message to a platform microcontroller, which takes a bounded time. Some message protocols are instead processed on the calling hart itself, for example when the SBI implementation forwards the message to another supervisor domain and switches the hart to it until it responds (this is the model of the TEE service group of RPMI v2.0, where TEE_CALL runs the target TEE on the hart of the caller). Such processing is unbounded and depends on interrupts reaching the other domain so that it can yield. Sending such messages through mbox_send_message() is not an option: the mailbox core calls the controller send_data() callback from msg_submit() with the channel spinlock held and interrupts disabled. Every hart would then serialize on a single spinlock, spinning with interrupts disabled for the whole duration of a message processed on another hart, while the calling hart would run the other domain with the channel lock held. Add riscv_sbi_mpxy_mbox_call() which performs the RPMI transfer directly in the calling context, bypassing the mailbox core queue and channel lock. The channel must still be requested through the mailbox core so that its ownership is tracked. Local interrupts are disabled around the ecall since the per-hart shared memory is also used from hard interrupt context by mbox_send_message() users such as the RPMI system MSI irqchip; calls from different harts proceed in parallel because each hart has its own shared memory. Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The SMC ABI is defined in terms of register arguments and return values and does not depend on how they reach secure world: smc_abi.c already abstracts the conduit behind optee_invoke_fn, only its selection is hard-wired to the SMCCC "method" property of the "linaro,optee-tz" node. Introduce struct optee_smc_conduit carried by the match data of the firmware node, move the SMCCC specific wrappers and the "method" property parsing into the SMCCC conduit and build that conduit only when the architecture provides SMCCC (__arm_smccc_hvc() has no stub when CONFIG_HAVE_ARM_SMCCC is not set). This prepares for a conduit that carries the SMC ABI over RISC-V RPMI messages. No functional change on Arm. Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
optee_check_mem_type() only lets normal cacheable memory be registered with secure world since OP-TEE maps registered pages as such and must not observe mismatched memory attributes. On RISC-V the memory type of a mapping is encoded in the Svpbmt bits of the PTE (or their T-Head equivalent selected at runtime by the _PAGE_MTMASK alternative): normal cacheable memory (PMA) has them cleared, pgprot_writecombine() and pgprot_noncached() set them. Without Svpbmt the memory type is defined by the PMAs alone, _PAGE_MTMASK is empty and every mapping passes the check, as there is nothing else to inspect. Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The RPMI specification v2.0, currently in development on the main branch of the specification repository, adds a TEE service group (SERVICEGROUP_ID 0x0010) which lets a client in a Rich Execution Environment invoke services in a Trusted Execution Environment through the M-mode firmware or hypervisor implementing the group. Its TEE_CALL service is a synchronous request whose target TEE executes on the hart of the caller until a response is returned. Add the service group ID and the service IDs, as defined in the specification draft, so that TEE drivers can use them together with the SBI MPXY mailbox driver. Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
On RISC-V, OP-TEE runs as a supervisor domain isolated from the Rich Execution Environment by the M-mode firmware. There is no SMC or HVC instruction to reach it: the kernel invokes OP-TEE through the TEE service group of the RISC-V Platform Management Interface (RPMI) v2.0, carried on an SBI Message Proxy (MPXY) channel. Each call is a TEE_CALL service request whose service data carries the register arguments of the OP-TEE SMC ABI, so the ABI itself is unchanged from Arm. Add a binding for such an OP-TEE instance. The compatible string keeps the "linaro" vendor prefix of "linaro,optee-tz" which identifies the OP-TEE reference implementation. The node references the MPXY mailbox channel implementing the TEE service group, and carries the endpoint identifiers assigned by the RPMI TEE framework to the REE and to OP-TEE since the framework does not define any way for an endpoint to learn them other than the optional TEE_PROBE_SYSTEM service, whose CBOR encoded response cannot be parsed in the kernel. Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
On RISC-V, OP-TEE runs as a supervisor domain isolated from the Rich Execution Environment by the M-mode firmware. There is no SMC or HVC instruction to reach it: the kernel invokes OP-TEE through the TEE service group of the RISC-V Platform Management Interface (RPMI) v2.0, whose TEE_CALL service is carried by the SBI Message Proxy (MPXY) extension of SBI v3.0. 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 exactly 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. Add a conduit for the SMC ABI which sends the register arguments a0-a7 of each invocation as the service data of a TEE_CALL request and takes the return values a0-a3 from its service response, using the OP-TEE API UID as the service UUID. The TEE_CALL request and response follow the specification, only the content of the service data and of the service response, which the specification leaves to the service, is defined here. The message layout is in optee_rpmi.h which is kept in sync with OP-TEE OS like optee_smc.h and optee_msg.h. The SMC ABI itself, the message protocol, the RPC handling, dynamic and static shared memory and notifications are unchanged. The conduit binds to a "linaro,optee-rpmi" firmware node referencing the MPXY mailbox channel and carrying the REE and OP-TEE endpoint identifiers assigned by the framework. The channel is requested through the mailbox core to claim it, and its RPMI attributes are checked at probe, but TEE_CALL requests are sent with riscv_sbi_mpxy_mbox_call() rather than mbox_send_message(): OP-TEE executes on the calling hart for an unbounded time, which cannot happen under the mailbox channel spinlock with interrupts disabled. Errors reported by the SBI implementation or the framework, which mean that OP-TEE was not reached, are converted into OPTEE_SMC_RETURN_EBUSY or OPTEE_SMC_RETURN_ENOTAVAIL so that the callers see a failed call. Signed-off-by: Marouene Boubakri <marouene.boubakri@oss.nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR for series 1161681 applied to workflow__riscv__fixes
Name: tee: optee: RISC-V support over the RPMI TEE service group
URL: https://patchwork.kernel.org/series/1161681/
Version: 1