> Subject: Re: [Tee-dev] TEE with XEN > > Hi Peng, > > On Fri, 19 Jun 2020 at 12:06, Peng Fan <peng....@nxp.com> wrote: > > > > > Subject: Re: [Tee-dev] TEE with XEN > > > > > > > > > > > > > On 19 Jun 2020, at 09:52, Peng Fan <peng....@nxp.com> wrote: > > > > > > > > Hi Bertrand, > > > > > > > >> Subject: Re: [Tee-dev] TEE with XEN > > > >> > > > >> Hi, > > > >> > > > >>> On 18 Jun 2020, at 19:05, Julien Grall <jul...@xen.org> 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....@nxp.com> > 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.babc...@gmail.com
