[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Tee-dev] TEE with XEN


  • To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • From: Peng Fan <peng.fan@xxxxxxx>
  • Date: Fri, 19 Jun 2020 09:05:59 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OOnH1iBFRnHJ2a/DHiXrVHs2u9y+PQpdX0HHBIolzts=; b=JG4rSVZ/iW0Y57xpV5jLJoHNM7D4q7Y0mnMf3ks5JX2+MuM1u3UT00CkLaYFmYPL0QbsI1BSiBcDaoHcblVvM9wbw753S1lm+qZX7XELU3YRJz5aHDEFZvB533nPCKjf3OAXy170N9YwWFwKKC4YXCE/mkVaXXzXiefHOIe7Ch3ZO0DHNxql2xXVfjX+vDEoA+ZzRFNejGlggAVA5FWP2IHactJG7Ewdv1w0wi0S17dGS20r+x12YrDt7X2wzR/5zvqkIYrJMub0KDV02C0bHagiqt9F+aOBFXheTyom8hjMMobxbrFYheHG0/mWC9gShprFprEhER4TznpvnaoJZg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N2vcOqqoDwdSMohOFkbe67Q5cLdUjsZTUcGd6B38CT9LkPmJuvCP1m9bIXGVEm4taOHdkU7hOGKQpR6v/60zUWpgikfrTeD8vCJyS4D1KlcuzmziPQrLlZqOLLJ3ECCnXs+s3xGRRkhF1wsAMPfVfptGvlRcx8kmbdLF2I1mbPdLZTNK/bZP77+Ulnx8vwgr0eKHkqVBITep9CQ7fSt4PHBptFt6Gc15STiNCBlmbRwDManVrdKxvBMKXgQYScItz5TkuytPXRkaqLdAYC6EZettTYD9Z8N1b2fgILrLnSzIwub/xpZpNizbWMda3vP028bMiHs5igWY2hCeJLCdGA==
  • Authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=nxp.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>, Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>, "tee-dev@xxxxxxxxxxxxxxxx" <tee-dev@xxxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, nd <nd@xxxxxxx>, Jens Wiklander <jens.wiklander@xxxxxxxxxx>, Stefano Babic <sbabic@xxxxxxx>
  • Delivery-date: Fri, 19 Jun 2020 09:06:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAAHsEHgAAAD3awAABi1QAAADlWUA==
  • Thread-topic: [Tee-dev] TEE with XEN

> 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?

Thanks,
Peng.

> 
> Regards
> Bertrand


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.