On 10 Nov 2021, at 17:13, Jorge Pereira mailto:jorge@ssrc.tii.ae> wrote: Thanks, Gerwin, 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 subsystems. 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. Cheers, Gerwin

On 13 Nov 2021, at 19:19, Jorge Pereira mailto:jorge@ssrc.tii.ae> wrote: Ok, is there any rationale for not allowing the guest to directly invoke the secure world? This is a hardware feature supported by ARMv8 and I was wondering that unnecessary traps will just bring more performance overhead. Is there any security concern? The discussion hasn't really concluded on that yet, but the concern is that guest VM's in terms of security are untrusted code that must be presumed malicious, so they cannot be granted uncontrolled access to arbitrary high-privilege code (just because that code tends to be vendor-provided does not mean it is of high quality or trustworthy). This means the general mechanism should be conservative. We could think about exceptions, but that should only be done once we know there is an actual performance problem. Otherwise that would be a premature optimisation. So far it looks like those calls are infrequent and mostly needed at boot time. Cheers, Gerwin