|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Tee-dev] TEE with XEN
> On 19 Jun 2020, at 10:12, Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx> wrote: > > 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. I agree this is the best approach to make secure world handle several clients. But it might be the most complex one though. Using a VM for it might be easier but you need to check that it achieving the level of trust that you need. You could have a VM acting as a muxer/checker and passing down requests to the secure world The definitive answer really depends on the amount of effort, the level of security and your general system needs. Bertrand
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |