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

[Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>]

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.

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.

   Cons:
    * Overhead in XEN<->Mediator communication.
    * XEN needs to be modified to boot mediator domain before Dom0.
    * 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.

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

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

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