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.?
From: Gerwin Klein <kleing(a)unsw.edu.au>
Date: Wednesday, 10 November 2021 at 1:55 AM
To: devel <devel(a)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:
Relevant Arm documentation (SMC calling conventions):
Any opinions, concerns, alternative designs?
Devel mailing list -- devel(a)sel4.systems
To unsubscribe send an email to devel-leave(a)sel4.systems