RE: [Tee-dev] TEE with XEN

[Peng Fan <peng.fan@xxxxxxx>]

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

Thanks,
Peng.

> 
> Regards
> Bertrand