Re: [RFC PATCH 0/7] KVM: optee: Introduce OP-TEE Mediator for exposing secure world to KVM guests

[Yuvraj Sakshith <yuvraj.kernel@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5088 bytes --]

On Tue, Apr 01, 2025 at 07:13:26PM +0100, Marc Zyngier wrote:
> 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:
> > 
> > 1. Notify OP-TEE when a VM is created.
> > 2. Notify OP-TEE when a VM is destroyed.
> > 3. Any SMC to OP-TEE has to contain the VMID in x7. If its the hypervisor sending, then VMID is 0.
> > 4. Hypervisor has to perform IPA->PA translations of the memory addresses sent by guest.
> > 5. Memory shared by the VM to OP-TEE has to remain pinned.
> > 6. 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.
>
Yes, this was an argument at the time of designing this solution.

> 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
>

Major reason why I went with placing the implementation inside the kernel is,
	- OP-TEE userspace lib (client) does not support sending SMCs for VM events
	  and needs modification.
	- QEMU (or every other VMM)  will have to be modified.
	- OP-TEE driver is anyways in the kernel. A mediator will just be an addition
		and not a completely new entity.
	- (Potential) issues if we would want to mediate requests from VM which has
	  private mem.
	- Heavy VM exits if guest makes frequent TOS calls.

Hence, the thought of making changes to too many entities (libteec, VMM, etc.) was a
strong reason, although arguable.

> 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
>

Yes, you're right. Although I believe there still are some changes that need to be made
to KVM for facilitating this. For example, kvm_smccc_get_action() would deny TOS call.

So, having an implementation completely in VMM without any change in KVM might be challenging,
any potential solutions are welcome.
 
> 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.
> 
> -- 
> Jazz isn't dead. It just smells funny.