> On 18 Jun 2020, at 23:17, Stefano Stabellini <sstabell...@kernel.org> wrote: > > On Thu, 18 Jun 2020, Julien Grall wrote: >> +Bertrand and Stefano > > Thanks for CC'ing me > > >> 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? >> >>>> >>>> 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). > > Given that Secure World has access to Normal World but not vice versa, > it is more natural to run Trusty in one of the Secure execution levels. > The expectation is that Trusty has higher privilege, thus it is more > "trusted" than anything running in Normal World, including Xen. > > Of course no client should be able to crash Trusty, so the reality > sometimes can be very different from the theory :-) > > If I were you, I would consider running the TEE "inside" the VM only if > the service that the TEE provides is strongly coupled with the VM and > doesn't actually need a high level of privilege to function (i.e. > doesn't access secure devices or at least not often.) >
I could see some scenarios where this would make sense if you trust one VM more then an other. But this falls into a model of “virtualizing” optee using a VM where from the system point of view any usage of this VM from the functionality could not be more trusted then Xen And the VM providing the service. > >> 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. > > This would most probably be the best compromise. Agree. Bertrand
