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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 24 Oct 2017, Volodymyr Babchuk wrote:
> > > > >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...

OK :-)


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

I think it is fine to support OP-TEE only in Dom0 to begin with.

Ideally, it would be in Dom0 for convenience and speed and the OP-TEE
capability would be specified as an XSM label. Ideally, it would not be
only in Dom0 because it is tied to the 1:1 map, but I understand now
that it is a requirement. I still think that the XSM label would be good
to have even if today it cannot be changed as only Dom0 is 1:1.


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

It is possible to get a request from the command buffer in Xen, then
forward it to the stubdom over a separate ring. This is pretty much how
QEMU works on x86 to do emulation: IO accesses are trapped in Xen, then
Xen issues requests to QEMU over a special ring. Xen doesn't need to
forward to QEMU all requests: some of them could be handled directly in
Xen.

But maybe this model doesn't actually make sense for OP-TEE?

Would it make sense to extract a request from the ring in Xen then
evaluate whether it should be handled in Xen, forwarded to the firmware,
or forwarded to a stubdom?

For example, would it be possible to forward to firmware accesses to
certain TAs while forwarding to a stubdom accesses to other TAs?

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