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

[Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>]

On Fri, Oct 20, 2017 at 02:11:14PM +0100, Julien Grall wrote:
> Hi Volodymyr,
Hi Julien,

> On 17/10/17 16:59, Volodymyr Babchuk wrote:
> >On Mon, Oct 16, 2017 at 01:00:21PM +0100, Julien Grall wrote:
> >>
> >>
> >>On 11/10/17 20:01, Volodymyr Babchuk wrote:
> >>>Hello all,
> >>
> >>Hi Volodymyr,
> >Hi Julien
> >>
> >>>
> >>>I want to present TEE mediator, that was discussed earlier ([1]).
> >>>
> >>>I selected design with built-in mediators. This is easiest way,
> >>>it removes many questions, it is easy to implement and maintain
> >>>(at least I hope so).
> >>
> >>Well, it may close the technical questions but still leave the security
> >>impact unanswered. I would have appreciated a summary of each approach and
> >>explain the pros/cons.
> >This is the most secure way also. In terms of trust between guests and
> >Xen at least. I'm worked with OP-TEE guys mostly, so when I hear about
> >"security", my first thoughts are "Can TEE OS trust to XEN as a
> >mediator? Can TEE client trust to XEN as a mediator?". And with
> >current approach answer is "yes, they can, especially if XEN is a part
> >of a chain of trust".
> >
> >But you probably wanted to ask "Can guest compromise whole system by
> >using TEE mediator or TEE OS?". This is an interesting question.
> >First let's discuss requirements for a TEE mediator. So, mediator
> >should be able to:
> >
> >  * Receive request to handle trapped SMC. This request should include
> >    user registers + some information about guest (at least domain id).
> >  * Pin/unpin domain memory pages.
> >  * Map domain memory pages into own address space with RW access.
> >  * Issue real SMC to a TEE.
> >  * Receive information about guest creation and destruction.
> >  * (Probably) inject IRQs into a domain (this can be not a requester domain,
> >    but some other domain, that also called to TEE).
> >
> >This is a minimal list of requirements. I think, this should be enough to
> >implement mediator for OP-TEE. But I can't say for sure for other TEEs.
> >
> >Let's consider possible approaches:
> >
> >1. Mediator right in XEN, works at EL2.
> >    Pros:
> >     * Mediator can use all XEN APIs
> >     * As mediator resides in XEN, it can be checked together with XEN
> >       for a validity (trusted boot).
> >     * Mediator is initialized before Dom0. Dom0 can work with a TEE.
> >     * No extra context switches, no special ABI between XEN and mediator.
> >
> >    Cons:
> >     * Because it lives in EL2, it can compromise whole hypervisor,
> >       if there is a security bug in mediator code.
> >     * No support for closed source TEEs.
> 
> Another cons is you assume TEE API is fully stable and will not change.
> Imagine a new function is added, or a vendor decided to hence with a new set
> of API. How will you know Xen is safe to use it?
With whitelisting, as you correctly suggested below. XEN will process
only know requests. Anything that looks unfimiliar should be rejected.

> If it is not safe, this means you have a whitelist solution and therefore
> tie Xen to a specific OP-TEE version. So if you need to use a new function
> you would need to upgrade Xen making the code of using new version
> potentially high.
Yes, any ABI change between OP-TEE and its clients will require mediator
upgrade. Luckilly, OP-TEE maintains ABI backward-compatible, so if you'll
install old XEN and new OP-TEE, OP-TEE will use only that subset of ABI,
which is known to XEN.

> Also, correct me if I am wrong, OP-TEE is a BSD 2-Clause. This means you
> impose anyone wanted to modify OP-TEE for their own purpose can make a
> closed version of the TEE. But if you need to introspect/whitelist call, you
> impose the vendor to expose their API.
Basically yes. Is this bad? OP-TEE driver in Linux is licensed under GPL v2.
If vendor modifies interface between OP-TEE and Linux, they anyways obligued
to expose API.

> >
> >2. Mediator in a stubdomain. Works at EL1.
> >    Pros:
> >     * Mediator is isolated from hypervisor (but it still can do potentially
> >       dangerous things like mapping domain memory or pining pages).
> >     * One can legally create and use mediator for a closed-source TEE.
> 
>        * Easier to upgrade to a new version of OP-TEE.
Yes, this is true. But what about interface between XEN and mediator?
This is a new entity that should be maintained. Will I abe able to use
new XEN with old mediator? Or new mediator with old XEN?

> >>     Cons:
> >     * Overhead in XEN<->Mediator communication.
> >     * XEN needs to be modified to boot mediator domain before Dom0.
> 
> Is it a really cons? In the past, we had discussion to allow Xen creating
> multiple domain, avoiding the overhead of Dom0. This could also benefits
> here.
As I understand, this is a significant change in XEN. What are the chances,
that community will accept this change? As I can see, immediate benefit
of this is only TEE mediator support. Looks like no one except us
interested in this topic.

BTW, I checked "Xen on ARM: create multiple guests from device
tree" at [1]. This is close, to what we need, but not exactly. You see,
TEE mediator should be created *before* Dom0. So actually TEE mediator
will receive domid 0. I suspect that this only change will break
many things.

> >     * Some extra entity required to check validity of a mediator.
> >
> >3. Mediator in an EL0 app.
> >    The same pros and cons as for mediator in a stubdomain + extra code for 
> > EL0
> >    apps, which is needed to be supported and maintained.
> >
> >Now, back to security questions. There are two possible attacks:
> >attack at XEN and attack at TEE itself.
> >
> >If your TEE is vulnerable, then your whole system is compromised anyways.
> >AFAIK, this approach was used to hack Samsung phones. Some flaw in Qualcom's
> >TZ implementation.
> >
> >If your TEE mediator is vulnerable, then your hypervisor and all guests are
> >compromised. Yes TEE mediator increases attack surface, but the same does
> >any other XEN<->Guest interface. TEE mediators are expected to be simple
> >and straightforward, without complex logic. So, I think that they are not
> >more dangerous than vGIC driver or PL011 emulator.
> 
> To be honest when I read the list that a mediator should be able to do, I
> don't think it is possible to say it will not have complex logic.
Maybe we have different opinion on what is "complex" :) This is pretty
straightforward: map memory, cast it to comand buffer structure, examine
types of parameters.

> For instance, for memory pinning. You need to know the buffers which likely
> means introspection of the calls if there are nested buffers.
>
> This implies that you may tie into a specific version of TEE for a specific
> version of Xen.
As I said, OP-TEE maintains backward-compatible interface. Can't say
for other TEEs, though.

> So how do you expect OP-TEE evolving with Xen support? For example, if there
> is a new function do you expect to work on previous version of Xen? Or shall
> it wait the next release?
OP-TEE interface does not change much from version to version. I know about
three of that changes. They all was upstreamed in OP-TEE OS, but only one
is being upstreamed into optee client right now. So, vanilla Linux right
now support only the basic OP-TEE interface. Custom builds can work with
all extensions. I don't think, that is big deal if XEN mediator will
lag one version behind, relative to OP-TEE.

> >
> >And yes, it seems obvious, but I want to say this explicitly: generic
> >TEE mediator framework should and will use XSM to control which domain
> >can work with TEE. So, if you don't trust your guest - don't let it
> >to call TEE at all.
> 
> Correct me if I am wrong. TEE could be used by Android guest which likely
> run the user apps... right? So are you saying you fully trust that guest and
> obviously the user installing rogue app?
I don't think that app downloaded from Play Marget can access OP-TEE directly.
OP-TEE can be used by Android itself as a key storage or to access to a SE,
for example. But 3rd app that issues TEE calls... I don't think so.

> >This feature is not implemented in this RFC only because
> >currently only Dom0 calls are supported.
> >
> >>This would help to understand that maybe it is an easy way but also still
> >>secure...
> >In previous discussion we considered only two variants: in XEN or outside
> >XEN. Stubdomain approach looks more secure, but I'm not sure that it is true.
> >Such stubdomain will need access to all guests memory. If you managed to
> >gain control on mediator stubdomain, you can do anything you want with all
> >guests.
> 
> That's slightly untrue. The stubdomain will only be able to mess with
> domains using TEE.
Yes, this is more strict. Then either you are not allowing your privileged
domain to use TEE, or your system may be compromised anyways.

> >
> >>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. Even now, XEN processes requests from DomUs without
trusting them. Why do you think, that TEE mediator usage will differ?

Look, I generally not against idea of TEE mediator in stubdoms. But this
approach require many changes in existing XEN code:

1. Load domains before Dom0.

2. Add special API for mediator. Or alter existing ones. You can't use
   existing APIs as it, because you need to enforce stricter XSM rules
   on them.

3. Changes in scheduling to allow TEE mediator use credits/slices of
   calling guest.

4. Support boilerplate code in stubdom. You know, you can't simply
   write mediator in stubdom. You need a kernel. You need to
   maintain it.

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?

Approach in this RFC is much simpler. Few hooks in arch code + additional
subsystem, which can be easily turned off.

[1] https://wiki.xenproject.org/wiki/Outreach_Program_Projects

WBR, Volodymyr Babchuk

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