RE: [Tee-dev] TEE with XEN

[Peng Fan <peng.fan@xxxxxxx>]

Hi Bertrand,

> Subject: Re: [Tee-dev] TEE with XEN
> 
> Hi,
> 
> > On 18 Jun 2020, at 19:05, Julien Grall <julien@xxxxxxx> wrote:
> >
> > +Bertrand and Stefano
> >
> > On 16/06/2020 02:24, Volodymyr Babchuk wrote:
> >> Hi Peng,
> >> On Mon, 15 Jun 2020 at 05:07, Peng Fan <peng.fan@xxxxxxx> wrote:
> >>>
> >>> Hi All,
> >>>
> >>> While enabling trusty os with xen, I took same approach as OP-TEE,
> >>> with OP-TEE running in secure world. But I am also thinking this
> >>> might introduce potential issue is that secure world OS communicate with
> DomU.
> >>> If there are some misbehavior in secure world OS, it might let XEN
> >>> hypervisor not work proper.
> >>>
> >>> In my setup, trusty os sometimes panic in secure world, xen will not
> >>> able to control the panic core anymore.
> >
> > May I ask in which case Trusty is panicking?
> 
> In any case, optee should protect itself against this and it should be
> considered that optee is more priviledged then Xen.
> So if optee is crashing we cannot expect that Xen can recover or fix it.
> 
> I would more consider this as a bug that optee needs to be robust against.

ok. I am not using OP-TEE, currently I use google trusty OS.

I have two OS, Dom0 linux + DomU android auto.

DomU android auto needs trusty OS, Dom0 Linux not need that.

I not wanna trusty OS for DomU could bring any detect to Dom0 or xen.

One more case is if dom0 linux needs OP-TEE, DomU needs google trusty,
how we handle this in one SoC?

> 
> >
> >>>
> >>> So I am thinking whether we need to emulating secure world in a XEN
> >>> VM which is the VM running DomU. Just like what ACRN did to run
> >>> trusty os.
> >> Well, it depends on whom you are trusting more. Both XEN and TEE are
> >> minimal OS implementations with aim at security. I'm speaking about
> >> generic TEE OS, not about particular OS like OP-TEE or Trusty.
> >> Problem is that, if TEE is running inside VM, it will be susceptible
> >> to a hypervisor misbehaviour. You need to understand that Xen and
> >> privileged domain (dom0, mostly) can access memory of any guest.
> >> At least, in default configuration. There are means to harden this
> >> setup. But anyways, Xen can't be stopped from reading TEE's secrets.
> >
> > IIRC, we discussed this approach for OP-TEE in the past. There was other
> potential pitfalls with it. For instance, you wouldn't be able to directly 
> access
> any secure device from that guest (it is running in non-secure world).
> >
> > There are also issues in term of latency as you may have the following
> model:
> >
> > domU -> Xen -> domU TEE -> (Xen -> host TEE -> Xen -> domU TEE) -> Xen ->
> domU.
> >
> > The bit in () is if you require to call the host TEE.
> >
> > One possibility would be to use Secure-EL2 for your Trusty OS. But I don't
> know whether your platform supports it.
> >
> > Depending on whether you can modify Trusty OS, alternative would be to
> make itvirtualization aware as OP-TEE did. The core would need to be
> resilient and the panic only affect a given client.
> 
> I do not have right a clear idea of what is the status of optee and xen but in
> theory I would see 2 possible ways to handle this:
> - without optee modification, something in a guest (Dom0 or an other
> priviledged one) needs to have access to optee and emulate optee access for
> others.
> - with optee modifications, optee needs to have a concept of client and Xen
> would need to passthrough optee requests but being responsible of adding a
> “client” identifier. Maybe also informing Optee when a new client is
> created/removed.
> 
> The second scenario could then be somehow splitted in the previous one from
> Julien if some parts would need to be emulated somewhere in some kind of
> combination of the 2 models.
> 
> In any case i would always consider that anything running on optee (or in
> general in the secure world) is more trusted then Xen.

Ok, this means optee runs on all cores in secure world, but this would not
work when we need to support multiple OSes with their own TEE.

Regards,
Peng.

> 
> Regards
> Bertrand