Re: [Xen-devel] [RFC 0/4] TEE mediator framework + OP-TEE mediator

[Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>]

Hello Stefano

On Mon, Oct 23, 2017 at 02:26:56PM -0700, Stefano Stabellini wrote:

> > > >This is a lot of a work. It requires changes in generic parts of XEN.
> > > >I fear it will be very hard to upstream such changes, because no one
> > > >sees an immediate value in them. How do you think, what are my chances
> > > >to upstream this?
> > > 
> > > It is fairly annoying to see you justifying back most of this thread with
> > > "no one sees an immediate value in them".
> > >
> > > I am not the only maintainers in Xen, so effectively can't promise whether
> > > it is going to be upstreamed. But I believe the community has been very
> > > supportive so far, a lot of discussions happened (see [2]) because of the
> > > OP-TEE support. So what more do you expect from us?
> > I'm sorry, I didn't mean to offend you or someone else. You, guys, can
> > be harsh sometimes, but I really appreciate help provided by the
> > community. And I, certainly, don't ask you about any guarantees or
> > something of that sort.
> > 
> > I'm just bothered by amount of required work and by upstreaming
> > process. But this is not a strong argument against mediators in
> > stubdoms, I think :)
> > 
> > Currently I'm developing virtualization support in OP-TEE, so in
> > meantime we'll have much time to discuss mediators and stubdomain
> > approach (if you have time). To test this feature in OP-TEE I'm
> > extending this RFC, making optee.c to look like full-scale mediator.
> > I need to do this anyways, to test OP-TEE. When I'll finish, I can
> > show you how mediator can look like. Maybe this will persuade you to
> > one or another approach.
> 
> Hi Volodymyr,
> 
> We really appreciate your work and we care about your use-case. We
> really want this feature to be successful for you (and everybody else).
> 
> Sorry if it doesn't always come out this way, but email conversations
> can sound "harsh" sometimes. However, keep in mind that both Julien and
> I are completely on your side on this work item. Please keep up with the
> good work :-)
Thanks :-)

> 
> > > >Approach in this RFC is much simpler. Few hooks in arch code + additional
> > > >subsystem, which can be easily turned off.
> > > 
> > > Stefano do you have any opinion on this discussion?
> 
> We need to start somewhere, and I think this series could be a decent
> starting point.
>
> I think it is OK to have a small SMC filter in Xen. What Volodymyr is
> suggesting looks reasonable for now. As the code grows, we might found
> ourselves in the situation where we'll have to introduce stubdoms for
> TEE virtualization/emulation, and I think that's OK. Possibly, we'll
> have a "fast path" in Xen, only for filtering and small manipulations,
> and a "slow path" in the stubdom when more complex actions are
> necessary.
This sounds a bit tricky, actually. If I got you right, you are
proposing to split mediator into two parts. Only benefit I can see
there - fast calls to OP-TEE from Dom0. That probably can work, but I
need to consider all consequences...

> For this series, I think we need a way to specify which domains can talk
> to TEE, so that we can only allow it for a specific subset of DomUs. I
> would probably use XSM for that.
I am afraid, this is not possible. As other domains aren't 1:1 mapped,
I need to have special translation code in mediator. Actually, I'm
writing it rigth now to test my changes in OP-TEE. But event this is
not enought for decent OP-TEE support.
What can be done right now: 100% Dom0-only support with vanilla
OP-TEE (i.e. no virtualization support in OP-TEE is needed). This is
even simplier task, so I can throw out some code from this patch
series. On other hand, in the future this will lead to sutiation when
two mediators for the same TEE shall be supported: one, simple, in
XEN, another, fully-functional in stubdom.

> For the long term, I think both Volodymyr and us as maintainers need to
> be prepared to introduce stubdoms for TEE emulation. It will most
> probably happen as the feature-set grows. However, this small TEE
> framework in Xen could still be useful, and could be the basis for
> forwarding TEE requests to a stubdom for evaluation: maybe not all calls
> need to be forwarded to the stubdom, some of them could go directly to
> the firmware and this is where this series comes in.
> 
> What do you think?
Hmm... I can't imagine how this can work for OP-TEE. In OP-TEE
protocol, there is a number of "fast" (in SMCCC terms) service calls,
which called mostly during initialization (to probe UID and version,
to get shared region location, to exchange caps and so on) and one
"yielding" (again, SMCCC term) call for actuall TEE tasks. The later
one passes arguments in command buffer (not in registers), it can
cause so-called RPC returns (when OP-TEE asks Normal World to perform
certain work). Most of the mediator code will be devoted to handle
this one type of call. So, I don't see benefit in splitting mediator
between XEN and stubdom. At least for OP-TEE. Maybe this is not true
for other TEEs.
Looks like Google Trusty employs another approach for NW<->SW
communication, maybe it can work in theirs case...



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