Re: [RFC 4/4] arm: tee: add basic OP-TEE mediator

[Julien Grall <julien.grall@linaro.org>]

Hi,

On 19/10/17 17:37, Volodymyr Babchuk wrote:
> On Thu, Oct 19, 2017 at 05:12:17PM +0100, Julien Grall wrote:
> 
> Hi Julien,
> 
>>>>>>>>> +    if ( rc < 0 )
>>>>>>>>> +    {
>>>>>>>>> +        gprintk(XENLOG_INFO, "OP-TEE: Can't map static shm for Dom0: %d", rc);
>>>>>>>>
>>>>>>>> gprintk already dump the domid. So no need to say Dom0.
>>>>>>> I just wanted to emphasis that we mappaed memory for Dom0. Will remove.
>>>>>>
>>>>>> gprintk will printk d0. So there are no point to say it a second time...
>>>>>>>
>>>>>>>>> +        set_user_reg(regs, 0, OPTEE_SMC_RETURN_ENOTAVAIL);
>>>>>>>>> +    }
>>>>>>>>> +
>>>>>>>>> +    return true;
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +static bool handle_exchange_capabilities(struct cpu_user_regs *regs)
>>>>>>>>> +{
>>>>>>>>> +        forward_call(regs);
>>>>>>>>> +
>>>>>>>>> +        printk("handle_exchange_capabilities\n");
>>>>>>>>
>>>>>>>> Same here, no plain prink.
>>>>>>> Sorry, this is another debug print. Missed it when formatted patches.
>>>>>>>
>>>>>>>>> +        /* Return error back to the guest */
>>>>>>>>> +        if ( get_user_reg(regs, 0) != OPTEE_SMC_RETURN_OK)
>>>>>>>>> +            return true;
>>>>>>>>> +
>>>>>>>>> +        /* Don't allow guests to work without dynamic SHM */
>>>>>>>>
>>>>>>>> Hmmm? But you don't support guests today. So why are you checking that?
>>>>>>> This is a RFC. Will remove this parts of the code in a proper patch series.
>>>>>>>
>>>>>>> I just wanted to ensure that community is okay with proposed approach and
>>>>>>> to show how minimalistic mediator can look.
>>>>>> I don't think this is true. You only show how easy it is to let Dom0
>>>>>> accessing TEE. And as I said in the cover letter, this is not the
>>>>>> controversial part.
>>>>> Actually I wanted to show approach when mediator resides right in xen.
>>>>> I got valuable input from you. Now I see that I must completely rework the
>>>>> first patch. And, probably, show more comprehensive support from OP-TEE side.
>>>>>
>>>>>> The more controversial one is the guest support that you completely left
>>>>>> aside. I believe this part will not be as minimalistic as you think because
>>>>>> you need to translate buffer address and prevent those buffers to disappear
>>>>>> under your feet.
>>>>> Yes. I plan to copy all buffers where IPAs presented to another place,
>>>>> so DomU will not be able to see PAs during translation. And I plan to
>>>>> pin all DomU pages with a data. Also I'll read from guest pages only
>>>>> once. I think, this will be enough.
>>>>>
>>>>>> There are probably other problem to fix...
>>>>> Probably yes...
>>>>>
>>>>> I think, I'll focus on OP-TEE side right now and come back when there will
>>>>> be more more to show.
>>>>
>>>> To clarify my view. I am not against a temporary support of OP-TEE for the
>>>> hardware domain in Xen. But it does not mean I would be ready to see  the a
>>>> full OP-TEE support for guests in Xen.
>>> Hm. What did you mean in last sentence? Our (here, at EPAM) target is full
>>> virtualization support for OP-TEE. If you don't want to see it in Xen,
>>> then what another ways we have?
>>
>> Sorry it was not clear enough. I meant that whilst I am happy to see OP-TEE
>> support for the hardware domain in the hypervisor, we still need to discuss
>> on the approach for guests.
> Excuse me, I still didn't get it. You imply that we need some
> completely different approach for guests? Or I can stick with current
> approach, just add more restrictions?
> 
> Under "current approach" I mostly mean "handle SMCs to TEE at EL2" as
> opposed to "handle them in stubdom". Half patches of this RFC should
> be severely reworked anyways.

Let me answer on your cover letter. That would be easier to draw a 
decision with your last e-mail.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel