Re: [Tee-dev] TEE with XEN

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

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.

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.

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