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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 23 Oct 2017, Volodymyr Babchuk 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 :-)


> > >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.

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.

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?

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