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.?
From: Gerwin Klein kleing@unsw.edu.au Date: Wednesday, 10 November 2021 at 1:55 AM To: devel devel@sel4.systems Subject: [seL4] RFC-9: new capability for seL4 SMC Forwarding on Arm I’d like to solicit discussion on the new RFC on forwarding Secure Monitor Calls on Arm: https://sel4.atlassian.net/browse/RFC-9
Relevant Arm documentation (SMC calling conventions): https://developer.arm.com/documentation/den0028/latest?_ga=2.116565828.39037...
Any opinions, concerns, alternative designs?
Cheers, Gerwin
_______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems