RE: [Tee-dev] TEE with XEN

[Peng Fan <peng.fan@xxxxxxx>]

> Subject: Re: [Tee-dev] TEE with XEN
> 
> Hi Peng,
> 
> On Fri, 19 Jun 2020 at 12:06, Peng Fan <peng.fan@xxxxxxx> wrote:
> >
> > > Subject: Re: [Tee-dev] TEE with XEN
> > >
> > >
> > >
> > > > On 19 Jun 2020, at 09:52, Peng Fan <peng.fan@xxxxxxx> wrote:
> > > >
> > > > 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.
> > >
> > > Sorry i should have been more generic.
> > > Please read this as “Anything running in secure world”, being optee or
> trusty.
> > >
> > > >
> > > > I have two OS, Dom0 linux + DomU android auto.
> > > >
> > > > DomU android auto needs trusty OS, Dom0 Linux not need that.
> > >
> > > But i would guess your Dom0 is more “critical” then your DomU.
> > > In this case you must make sure that any resource given to your DomU
> > > cannot affect your Dom0.
> > > For example: if the DomU is starting a very heavy operation in
> > > blocked in trusty, any interrupt for non-secure could be blocked,
> > > thus affecting the ability of your Dom0.
> > >
> > > >
> > > > 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?
> > >
> > > You have a shared resource in this case, someone more or as trusted
> > > as the clients needs to decide how the resource can be shared.
> > > In this case could be Dom0 or Xen or Trusty or op-Tee (if i should
> > > make an order).
> > >
> > > >
> > > >>
> > > >>>
> > > >>>>>
> > > >>>>> 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.
> > >
> > > I would think you have one TEE running on all cores (or runnable in this
> case).
> > > So the Tee needs to handle several contexts or someone needs to
> virtualize it.
> >
> > This back to my original question, should I virtualize TEE in a XEN 
> > dedicated
> VM?
> > or I need to emulate secure world to let one VM could have secure and
> > non-secure world?
> >
> 
> Well, I think that the best approach is that we did in the OP-TEE: make Trusty
> virtualization-aware, so it can handle multiple VMs.

Trusty virtualization-aware, you mean android Linux trusty driver communicate
with OP-TEE or else?

> 
> Things are more funny if you want to use multiple different TEEs (like OP-TEE
> and Trusty) at the same time. If this is your case, then the best approach is 
> to
> implement something like para-virtualization in the Secure World. But this
> would require quite big efforts, of course.

This is just a brainstorm idea, I not have the case right now. I just wanna
avoid trusty os that only work with android auto vm not break dom0 and
xen. 

Thanks,
Peng.

> 
> --
> WBR Volodymyr Babchuk aka lorc [+380976646013]
> mailto: vlad.babchuk@xxxxxxxxx