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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Volodymyr,

On 02/11/17 20:07, Volodymyr Babchuk wrote:
> On Thu, Nov 02, 2017 at 05:49:12PM +0000, Julien Grall wrote:
> > On 02/11/17 16:53, Volodymyr Babchuk wrote:
> > > On Thu, Nov 02, 2017 at 01:17:26PM +0000, Julien Grall wrote:
> > > > On 24/10/17 20:02, Volodymyr Babchuk wrote:
> > > But parameters are mapped every call and only needed ones.
> > > Example: I have shared buffers A, B, C, D.
> > >
> > > 1) I call OpenSession(TA_UUID, A, B).
> > >     TA sees only buffers A, B (okay, actually it sees whole page, because
> > >     buffer is mapped from userspace).
> > >
> > > 2) I call InvokeCommand(Session, CMD_ID, B, C).
> > >     TA sees only buffers B & C.
> > >
> > > 3) I call InvokeCommand(Session, CMD_ID, A, D).
> > >     TA sees only buffers A & D.
> > >
> > > Note, that such buffers are not mapped at OP-TEE address space at all.
> > > They will be mapped only to TA address space.
> > To confirm, what you are saying is as soon as any call is returned by TA,
> > the region will be unmapped from the TA address space?
> Yes.
> Also, just to clarify: TA executes only by request from client. It
> can't have external events. So, TA address space is somewhat ephemeral
> entity. It exists only during time between TA entry and TA exit. At
> all other times, TA does have no address space, no thread context,
> anything. Just code and data somewhere in memory.
That's quite a good news :). Thank you for the explanation.

> > > [...]
> > > > > > > > > > > > To be clear, this series don't look controversial at least for OP-TEE. What
> > > > > > > > > > > > I am more concerned is about DomU supports.
> > > > > > > > > > > Your concern is that rogue DomU can compromise whole system, right?
> > > > > > > > > > Yes. You seem to assume that DomU using TEE will always be trusted, I think
> > > > > > > > > > this is the wrong approach if the use is able to interact directly with
> > > > > > > > > > those guests. See above.
> > > > > > > > > No, I am not assuming that DomU that calls TEE should be trusted. Why do you
> > > > > > > > > think so? It should be able to use TEE services, but this does not mean that
> > > > > > > > > XEN should trust it.
> > > > > > > > In a previous answer you said: "So, if you don't trust your guest - don't
> > > > > > > > let it". For me, this clearly means you consider that DomU using TEE are
> > > > > > > > trusted.
> > > > > > > >
> > > > > > > > So can you clarify by what you mean by trust then?
> > > > > > > Well... In real world "trust" isn't binary option. You don't want to
> > > > > > > allow all domains to access TEE. Breached TEE user domain doesn't
> > > > > > > automatically mean that your whole system is compromised. But this
> > > > > > > certainly increases attack surface. So it is safer to give TEE access
> > > > > > > only to those domains, which really require it. You can call them
> > > > > > > sligtly more trusted, then others.
> > > > > > Do you have an example of guest you would slightly trust more?
> > > > > I have an example of guest I would trust less: if I'm running server,
> > > > > and I'm selling virtual machines on that server, I don't want to them
> > > > > to access TEE.
> > > > Make sense.
> > > >
> > > > > I will trust slightly more to my own guest.
> > > > I kind of agree if there are either no interaction with the user or the user
> > > > is not able to gain privilege permissions.
> > > Okay, if user can execute arbitrary code at EL1... Even then nothing bad
> > > will happen. They must be able to hack mediator/hypervisor/OP-TEE to realy
> > > gain priviegs in system.
> > My worry here is you base the trust on OP-TEE and not only the hypervisor.
> > At the moment we had to trust the hardware to do the right thing and the
> > software is owned by Xen.
> How about firmware? E.g. ARM TF?
My point here was anything involved in virtualization is at the moment 
the hardware and Xen. The ARM TF/firmware cannot be accessed 
directly/indirectly by any guest. So there are no concern to me.
> > Now you are telling me, we have this TEE running in EL3 and have to trust
> > him to do the isolation between guests. Until the last 2 e-mails, it was not
> > clear for me how OP-TEE could ensure this isolation.
> Actually, OP-TEE is running at S-EL1 :-) Only ARM TF (or whatever
> firmware is used) has ultimate control over the system. If we are
> talking about modern ARMv8 platforms.
>
> > I would advise to explain a bit more in your cover letter of your next
> > version the design of OP-TEE. This would help people to see how this can
> > work with the hypervisor and also understanding the consequence...
> I see. I'll do this, certainly. I just didn't expected that someone will
> be interested in OP-TEE internals at such level.
I like to understand what I sign for :).

> But, I think, cover leter for next OP-TEE will be done much later. Now,
> I'm busy with OP-TEE part, then there will be changes to support
> multi-domain boot and only then OP-TEE specific patches...
>
> BTW, if anyone is interested in current state of OP-TEE mediator, you
> can find it at [1]. I was able to pass OP-TEE tests from DomU in the
> last version. I use it for OP-TEE development, so it is not
> production-ready.
>
> Julien, I want to ask about VM monitor feature in XEN. monitor_smc()
> function and whole xen/arch/arm/monitor.c... Looks like it was
> introduced for some sort of debugging. Do you know any users of this
It was originally introduced to allow an external application trapping 
SMC and executing an action. This is part of the VM introspection 
framework that could be used to watch the behavior of the guest (see 
[2]). You could imagine trying to detect malware from outside the VM.
> [1] https://github.com/lorc/xen/tree/optee
[2] https://wiki.xenproject.org/wiki/Virtual_Machine_Introspection

--
Julien Grall

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