> 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? Thanks, Peng. > > Regards > Bertrand
