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

[Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>]

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.

WBR, Volodymyr

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