lchina77 writes:
Hi,
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.
Well, it depends on your requirements regarding security. For example, if you are trusting your hypervisor, you can run your TEE as an additional VM. In this case of course you will not get benefits of secure mode, but hypervisor extensions also provide quite serious degree of isolation
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.
Well, this is doable, of course. I believe, KVM guys tried to use the similar approach. In this case you must trust your HostVM, which, again, can be or can not be an issue.
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.
Yes, virtio-tee driver can act as TEE mediator in Xen hypervisor.
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?
As I said, this is completely doable. It would require some careful design, but I can't see any serious obstacles on this way.