[RISC-V] TEE invoke protocol/mechanism for RISC-V

[maroueneboubakri]

Hello,

Regarding the OP-TEE port to RISC-V, there still a big missing chunk which is the implementation of the protocol between OPTEED on non-secure environment and OP-TEE OS. For our current port we are using TEE SMC as it is, which is using ARM SMC calling convention, we want to come with more generic solution or dedicated solution for RISC-V, in the latter there is no defined specifications except of draft works.

What woul be the most convenient solution ?

• Grab the TEE SMC as it is and rename smc with a generic name ? sbi would not be the best option as OP-TEE OS may run on a sperate core(s) instead in top of SBI in same core as non-secure OS.
• Write a new protocol in addition to SMC and FFA ? but no specifications here.
• Kindky propose a better option.

Thank you ! Maro

[maroueneboubakri]

@gagachang @liushiwei007 FYI

[gagachang]

C.C. @fanghuaqi @matthewgui

[gagachang]

IMHO, the following source files could be referenced, even reused, for RISC-V. And they would be common interfaces for command handlers.

• core/arch/arm/kernel/thread_optee_smc.c
• core/arch/arm/tee/entry_fast.c

(If we want to follow RISC-V SBI calling convention, we can modify the register usage.)

sbi would not be the best option as OP-TEE OS may run on a separate core(s) instead in top of SBI in same core as non-secure OS.

I am trying to think a common protocol to support not only for same hart but also for separated harts.

How about using IPI ? In both use cases, REE S-mode Linux first ecall to M-mode SM to request for sending IPI.

• If OP-TEE run on same hart, SM performs OS context-switch to OP-TEE OS first, then SM sends IPI to the same hart.
• If OP-TEE run on separated hart, OS context-switch is unnecessary, SM just send IPI to the target hart.

A hartmask indicates which hart runs OP-TEE can be provided in device-tree. Of course the shared-memory might be necessary for the command forwarding between IPI.

[maroueneboubakri]

IMHO, the following source files could be referenced, even reused, for RISC-V. And they would be common interfaces for command handlers.

• core/arch/arm/kernel/thread_optee_smc.c
• core/arch/arm/tee/entry_fast.c

That's what I'm using right now, but SMC is ARM-related and I'm thinking on way to get rid of it, moving these files outside of arch will not be much meaningful.

(If we want to follow RISC-V SBI calling convention, we can modify the register usage.)

sbi would not be the best option as OP-TEE OS may run on a separate core(s) instead in top of SBI in same core as non-secure OS.

I am trying to think a common protocol to support not only for same hart but also for separated harts.

How about using IPI ? In both use cases, REE S-mode Linux first ecall to M-mode SM to request for sending IPI.

IPI is only valid for one domain, and can't be used for inter-domain communication. This will not be helpful when OP-TEE OS runs on seperate hart than the non-secure OS.

• If OP-TEE run on same hart, SM performs OS context-switch to OP-TEE OS first, then SM sends IPI to the same hart.
• If OP-TEE run on separated hart, OS context-switch is unnecessary, SM just send IPI to the target hart.

A hartmask indicates which hart runs OP-TEE can be provided in device-tree. Of course the shared-memory might be necessary for the command forwarding between IPI.

This stills a system level issue, but for now, what we want if we can re-use the SMC ABI for RISC-V and how we can procceed ? would copying or moving arch/arm/sm/* and thread_optee_smc.c works ? Is it sill valid to consider using smc in variables/functions ? or should we rename ? @jenswi-linaro

[jenswi-linaro]

This stills a system level issue, but for now, what we want if we can re-use the SMC ABI for RISC-V and how we can procceed ? would copying or moving arch/arm/sm/* and thread_optee_smc.c works ? Is it sill valid to consider using smc in variables/functions ? or should we rename ? @jenswi-linaro

I think you should copy it and rename it to something generic, perhaps abi instead of smc. The point here is to be able to transport a few (at most 8?) 32- or 64-bit words. You can perhaps keep things more uniform if you stick to 32-bit word. I guess you'll still use core/include/optee_msg.h.

[gagachang]

would copying or moving arch/arm/sm/* and thread_optee_smc.c works ?

Copying arch/arm/sm is unnecessary, since that folder is for ARMv7 which lacks of privileged secure monitor, if I remember.

I agree with copying thread_optee_smc.c and renaming the functions/variables. Also arch/arm/tee/entry_fast.c is necessary for linux-side driver probing.

RISC-V AP-TEE spec has already defined TEEI to be an M-mode interface between confidential/non-confidential environments. I am not sure if we can reuse that name: TEEI.

[fanghuaqi]

Grab the TEE SMC as it is and rename smc with a generic name ? sbi would not be the best option as OP-TEE OS may run on a sperate core(s) instead in top of SBI in same core as non-secure OS.

Regarding this sperated cores use case, what is the current solution on ARM? If in the same cores, I think build on top of SBI is the best solution, since Linux kernel also rely on SBI API now, and SBI API allow extension API support, when this TEE related SBI API is frozen, maybe can be defined as a part of SBI API for TEE.

[gagachang]

I think we can start from copying/renaming SMC-related files into RISC-V folder, to be common command handlers. The command handlers have common entries, for example:

uint32_t __weak __thread_std_XXX_entry(uint32_t a0, uint32_t a1, uint32_t a2,
                       uint32_t a3, uint32_t a4 __unused,
                       uint32_t a5 __unused)

Different protocols (e.g., SBI for same hart, or RPMSG(?) for separate harts) can implement their own C/ASM source files, prepare the registers/parameters, and invoke the above command handler entry.

[matthewgui]

Because there is no riscv specifications to define TEE call，riscv tee-ap define vm extension，i think currently we can follow ARM SMC, the riscv related implementation can be discussed in detail, but for now, we need to determine the implementation direction。

[liushiwei007]

Because there is no riscv specifications to define TEE call，riscv tee-ap define vm extension，i think currently we can follow ARM SMC, the riscv related implementation can be discussed in detail, but for now, we need to determine the implementation direction。

I think so too。

[github-actions[bot]]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.