On Tue, 01 Apr 2025 18:05:20 +0100, Yuvraj Sakshith yuvraj.kernel@gmail.com wrote:
A KVM guest running on an arm64 machine will not be able to interact with a trusted execution environment (which supports non-secure guests) like OP-TEE in the secure world. This is because, instructions provided by the architecture (such as, SMC) which switch control to the firmware, are trapped in EL2 when the guest is executes them.
This series adds a feature into the kernel called the TEE mediator abstraction layer, which lets a guest interact with the secure world. Additionally, a OP-TEE specific mediator is also implemented, which hooks itself to the TEE mediator layer and intercepts guest SMCs targetted at OP-TEE.
Overview
Essentially, if the kernel wants to interact with OP-TEE, it makes an "smc - secure monitor call instruction", after loading in arguments into CPU registers. What these arguments consists of and how both these entities communicate can vary. If a guest wants to establish a connection with the secure world, its not possible. This is because of the fact that "smc" by the guest are trapped by the hypervisor in EL2. This is done by setting the HCR_EL2.TSC bit before entering the guest.
Hence, this feature which I we may call TEE mediator, acts as an intermediary between the guest and OP-TEE. Instead of denying the guest SMC and jumping back into the guest, the mediator forwards the request to OP-TEE.
OP-TEE supports virtualization in the normal world and expects 6 things from the NS-hypervisor:
- Notify OP-TEE when a VM is created.
- Notify OP-TEE when a VM is destroyed.
- Any SMC to OP-TEE has to contain the VMID in x7. If its the hypervisor sending, then VMID is 0.
- Hypervisor has to perform IPA->PA translations of the memory addresses sent by guest.
- Memory shared by the VM to OP-TEE has to remain pinned.
- The hypervisor has to follow the OP-TEE protocol, so the guest thinks it is directly speaking to OP-TEE.
Its important to note that, if OP-TEE is built with NS-virtualization support, it can only function if there is a hypervisor with a mediator in normal world.
This implementation has been heavily inspired by Xen's OP-TEE mediator.
[...]
And I think this inspiration is the source of most of the problems in this series.
Routing Secure Calls from the guest to whatever is on the secure side should not be the kernel's job at all. It should be the VMM's job. All you need to do is to route the SMCs from the guest to userspace, and we already have all the required infrastructure for that.
It is the VMM that should:
- signal the TEE of VM creation/teardown
- translate between IPAs and host VAs without involving KVM
- let the host TEE driver translate between VAs and PAs and deal with the pinning as required, just like it would do for any userspace (without ever using the KVM memslot interface)
- proxy requests from the guest to the TEE
- in general, bear the complexity of anything related to the TEE
In short, the VMM is just another piece of userspace using the TEE to do whatever it wants. The TEE driver on the host must obviously know about VMs, but that's about it.
Crucially, KVM should:
- be completely TEE agnostic and never call into something that is TEE-specific
- allow a TEE implementation entirely in userspace, specially for the machines that do not have EL3
As it stands, your design looks completely upside-down. Most of this code should be userspace code and live in (or close to) the VMM, with the host kernel only providing the basic primitives, most of which should already be there.
Thanks,
M.