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

[marouene.boubakri@oss.nxp.com]

From: Marouene Boubakri <marouene.boubakri@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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv