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, &param, &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