At 2020-11-21 00:52:18, "Volodymyr Babchuk" Volodymyr_Babchuk@epam.com wrote:
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.
You mean , the virtio-tee device in the Host VM will act as TEE mediator, in order to transfer data between the correct Guest VM and OP-TEE , is it right ?
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.
Well the problem is how the HostVM tee driver can dispatch the RPC from OP-TEE to the correct receiver. That is , the Host VM tee driver calls invoke_fn() and get RPC from OP-TEE, in which case OPTEE_SMC_RETURN_IS_RPC(res.a0) is true, then how the function optee_handle_rpc(ctx, ¶m, &call_ctx); get the correct handler , the virtio-tee device or the Host VM tee-supplicant ?
It seems that only the paramter struct tee_context *ctx can be the judging condition, but I don't find the way to use it or add more info to it .
Could you please give me some suggestion ?
-- Volodymyr Babchuk at EPAM