Hi Li Cheng,

 

Could you please elaborate the problem you are trying to solve?

 

Is the issue that it is difficult to integrate a OP-TEE specific driver into a Hypervisor? You would need that in any case so that the Host VM can access the OP-TEE in Secure world through the Hypervisor. In the call sequence you have described, it seems that communication between the Guest VM and OP-TEE will now go via the Host VM.  Could you please help me understand how that helps.

 

Routing Guest VM to TEE data via the Host seems quite opposite to the direction of travel where there is no trust between the Guest and Host and Hypervisor and Host as far as address space isolation goes. The Host now gets dibs on every message between the Guest and TEE.

 

Virtio (as it stands) either requires the Guest to make its address space visible to the Host or bounce buffers in the Hypervisor. The former does not fly if address space isolation is the security goal (as above). The latter could run into performance issues but I am not an expert on this.

 

The approach we are working on is to replace a TEE specific driver in the Hypervisor with a driver that is agnostic of the TEE. This is achieved by standardising the role that the Hypervisor plays in communication between a Guest VM and the TEE. So you write the driver once and it works with all TEEs that follow the standard.

 

Hence my original question i.e. is this the problem you are looking to solve?

 

Cheers,

Achin

 

 

 

 

 

 

 

From: Tee-dev <tee-dev-bounces@lists.linaro.org> on behalf of lchina77 <lchina77@163.com>
Date: Friday, 20 November 2020 at 12:53
To: "tee-dev@lists.linaro.org" <tee-dev@lists.linaro.org>
Subject: [Tee-dev] virtio device for OP-TEE

 

Hi, 

    I don't know whether this is the right place to discuss,  sorry for bothering.

 

    OP-TEE OS has already support virtualization, but modification to the hypervisor is also necessary. But the proprietary Hypervisors are close sourced and some TEE OSes are alos close-sourced, such as QSEE from QualComm. So maybe virtio-tee is an alternative solution for the Guest VM to access the OP-TEE.



In detail, CA from Guest VM --> libteec.so (GuestVM) --> tee driver(GuestVM) -->optee_do_call_with_arg() --> invoke_fn()--> virtio-tee driver --> virtio-tee device(HostVM) --> libteec.so (HostVM) --> tee driver(HostVM) -->optee_do_call_with_arg() -->invoke_fn() --> TEEOS.



I think the virtio-tee device must transfer the RPC to the virtio-tee driver in the GuestVM, then to the tee-supplicant in the GuestVM, in order to load the TAs in the GuestVM.

 

In the HostVM, the tee-supplicant accesses the tee-driver through /dev/teepriv0, and the virtio-tee device accesses the tee-driver through /dev/teepriv1, So I wonder how the HostVM tee driver can dispatch the RPC from OP-TEE to the correct receiver , tee-supplicant or the virtio-tee device?



Best Regards,

Li Cheng



 



 




 

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.