Added TEE SBI Extension description

[liushiwei007]

To support secure service running, cpu running environments are divided into Trusted execution environment (TEE) and Rich Execution Environment (REE). This section describes how to switch between REE and TEE and how to start TEE.

Signed-off-by: liushiwei [email protected]

[jrtc27]

This is not a proper specification, it's got some clear Arm-specific naming that shouldn't be used in the context of RISC-V and it talks specifically about Linux but that's not the only OS in the world.

[matthewgui]

hi @liushiwei007 ,
i found you have committed TEE Extension to Opensbi(http://lists.infradead.org/pipermail/opensbi/2023-January/004158.html)

i want to ask you some questions about this:

1. security state parameter is passed by OS(REE OS/TEE OS), whether it was designed this way on purpose?

2. do you have a plan to deal with interrupt when TEE running?

thanks!

[liushiwei007]

This is not a proper specification, it's got some clear Arm-specific naming that shouldn't be used in the context of RISC-V and it talks specifically about Linux but that's not the only OS in the world.

You mean fiq_entry? Although we actually use linux and optee-os, we still wanted to avoid binding to linux or optee-os in the design of opensbi. Since optee-os was originally an ARM architecture project, but the RISCV code has now also been developed, We can have some discussion about specific problem points, I think it is possible to avoid the Arm-specific naming。

[liushiwei007]

hi @liushiwei007 , i found you have committed TEE Extension to Opensbi(http://lists.infradead.org/pipermail/opensbi/2023-January/004158.html)

i want to ask you some questions about this:

1. security state parameter is passed by OS(REE OS/TEE OS), whether it was designed this way on purpose?
2. do you have a plan to deal with interrupt when TEE running?

thanks!

Yes, we designed this way on purpose, we currently assume that the hardware is generic, so we need the caller to indicate the state.
In the case of generic hardware, the design requires that the entire TEE environment does not respond to interrupts, and TEE must run quickly. TEE is allowed to handle interrupts under our proprietary hardware and also has work in interrupt routing. The first time I submitted a patch, I was unfamiliar with the flow and guidelines of the process, so I omitted the proprietary hardware part.

[matthewgui]

Yes, we designed this way on purpose, we currently assume that the hardware is generic, so we need the caller to indicate the state.

secure monitor in opensbi can also hold the next secure state，because the process of linux requesting secure service is serial .
usually REE os is considered as non secure world although it may be verified before running. If REE os intentionally pass a secure state，Is there any problem of security？

In the case of generic hardware, the design requires that the entire TEE environment does not respond to interrupts, and TEE must run quickly. TEE is allowed to handle interrupts under our proprietary hardware and also has work in interrupt routing. The first time I submitted a patch, I was unfamiliar with the flow and guidelines of the process, so I omitted the proprietary hardware part.

Under your proprietary hardware, non-secure interrupt will route to REE os，secure interrupt will route to TEE os，This process is mainly guaranteed by hardware，not dispatching interrupt by M mode, yes？

thanks！

[liushiwei007]

secure monitor in opensbi can also hold the next secure state，because the process of linux requesting secure service is serial .
usually REE os is considered as non secure world although it may be verified before running. If REE os intentionally pass a secure state，Is there any problem of security？

You're right. It's possible to read the security status directly on our proprietary hardware. When considering general hardware, we chose REE OS or TEE OS to pass the security status flag. I think it is also feasible that opensbi holds the next secure state as you said. As for REE pretending to be TEE, I think it may cause system problems, but it will not lead to security data leakage. Because the REE return address is the same, but the context is different.

[liushiwei007]

Under your proprietary hardware, non-secure interrupt will route to REE os，secure interrupt will route to TEE os，This process is mainly guaranteed by hardware，not dispatching interrupt by M mode, yes？

We have added additional interrupts in M mode. When interrupt route appears, it will take the added interrupt in M state as the starting point, and no timer-related interrupt will be used.

[matthewgui]

@liushiwei007
ok，thanks for your quickly reply！

[matthewgui]

hi @liushiwei007 ，

According to RISCV SBI calling convention(https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/riscv-sbi.adoc#binary-encoding), a0-a7 is used as parameter between the supervisor and the SEE. a6 is funid, a7: extid.

just like RISCV SBI calling convention, ARM SMC calling convention define parameters passing during SMC exceptions.
(https://documentation-service.arm.com/static/6013e5faeee5236980d08619)
ARM SMC argument passing is x0-x6(or r0-r6 on arch32), x0(or r0) always pass SMC FID(include module name and funid), result is returned in x0-x3.
Arm common parameter is r1-r6, which is same as riscv r0-r5.

So RISCV SBI calling convention a0-a7 is enough for OPTEE,only need to add a2,a3 to result list.

If a5 register is used as security state flag, riscv common data parameter is one less than arm, whether it is sufficient still need to be check. if TEE Extension in opensbi manage the secure state, there is no problem about parameters

thanks!

[liushiwei007]

hi, @matthewgui ,
are you reading 2.6 SMC32/HVC32 argument passing? (https://documentation-service.arm.com/static/6013e5faeee5236980d08619) I see that the document says that R0-R7 is used to pass the argument.
In this case,, one register is missing. The current design is to continue with the ARM-based command code and add the ext id "TEE". These arm commands are processed under the TEE handle, so two riscv registers are used. Unless arm commands are transcoded at the linux driver level or opensbi does not conflict with these commands, riscv's a7 registers are equivalent to arm's a0 register, in which case additional registers may not be used.
On the other hand, state flag management by opensbi is optional.

[matthewgui]

hi @liushiwei007 ,
yes, r7 is used for Hypervisor, if using hypervisor, maybe need to encode extid with funcid to a7.

thanks!

[gagachang]

Unless arm commands are transcoded at the linux driver level or opensbi does not conflict with these commands, riscv's a7 registers are equivalent to arm's a0 register, in which case additional registers may not be used.

Hi @liushiwei007
Do you have any idea about how RISCV's a7 is equivalent to ARM's w0 ?

Seems that each SBI extension has ID range from extid_start to extid_end.
Maybe we can define TEE extension with a ID range to be additional function ID which are mapping from ARM's commands w0 ?

struct sbi_ecall_extension ecall_tee = {
	.extid_start = SBI_EXT_TEE_START,
	.extid_end = SBI_EXT_TEE_END,
	.handle = sbi_ecall_tee_handler,
};

[liushiwei007]

The current design is the same for RISC-V and ARM code at the linux generic level, so the conversion is placed at the architectural level. If pass the value of w0 directly to a7, it will definitely get an error; If you want to convert the value, it is actually feasible, but I worry that the later optee-os function will be added or deleted will involve this part of the modification

[gagachang]

The current design is the same for RISC-V and ARM code at the linux generic level, so the conversion is placed at the architectural level. If pass the value of w0 directly to a7, it will definitely get an error; If you want to convert the value, it is actually feasible, but I worry that the later optee-os function will be added or deleted will involve this part of the modification

Yes, SMCCC has additional bits such as fast call [30], service call owner [29:24], and function number [15:0].
Maybe we need to define RISC-V own calling convention for optee-os.

[andreiw]

Linux? Can we abstract this from the REE OS name?

[liushiwei007]

In fact, yes, but the actual validation of the project is using linux, so the description is somewhat biased.