On 10 Nov 2021, at 17:13, Jorge Pereira
That would be a useful feature to add on seL4. Not only for communicating with TEEs but
also, in some platforms there are subsystems that are proprietary and completely owned by
the secure world and non-secure OSes like Linux use the SMC interface to talk to those
I think we should do that in a very configurable way for different use-cases. The ones I
see now are the following:
1. Virtualizing the secure world interface by trapping all SMCs from the guest and
threads. Guest clients can use that interface according to SMC calling convention.
* This will involve changes in the kernel/VMM and several traps/contexts switching
but would allow multiple clients to access the secure world.
2. Exclusive assignment of the TZ TEE to a specific thread or guest OS (not to all of
them). That thread or guest would expose a virtual interface to multiple clients and would
forward client requests directly secure world.
* For a EL0 thread, it would require involvement of the kernel to forward the
request since SMC instructions are not allowed from EL0.
* For an EL0/EL1 guest, the vCPU running in EL1 would be able to switch the pCPU
control to the secure world without kernel intervention.
I think the use-case 1. is the one proposed in the RFQ. Is that right? Have you thought
about the use-case 2.?
I think both use cases are covered, even if not maybe directly. Use case 1 is covered
directly. For the exclusivity in use case 2, you would provide the relevant SMC cap(s)
only to the management thread(s) you dedicate for that task. EL0 can then talk to that
thread via IPC or could even be delegated a reduced version of the cap and invoke the cap
directly. A guest OS attempting a direct smc call would trap, which will invoke the
standard fault handler, which could be directly the management thread or could invoke the
management thread. Both of these would imply kernel action, but not via any new
mechanisms. The only new part is the SMC cap and its invocation.