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 <[email protected]>
Date: Wednesday, 10 November 2021 at 1:55 AM
To: devel <[email protected]>
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.390371079.1616755184-1989679030.1616755184
Any opinions, concerns, alternative designs?
Cheers,
Gerwin
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
