Re: [Xen-devel] [RFD] OP-TEE (and probably other TEEs) support

[Julien Grall <julien.grall@xxxxxxx>]

Hi Volodymyr,

On 29/11/16 17:40, Volodymyr Babchuk wrote:
> On 29 November 2016 at 18:02, Julien Grall <julien.grall@xxxxxxx> wrote:
> > On 29/11/16 15:27, Volodymyr Babchuk wrote:
> > > On 28 November 2016 at 22:10, Julien Grall <julien.grall@xxxxxxx> wrote:
> > > > On 28/11/16 18:09, Volodymyr Babchuk wrote:
> > > > > On 28 November 2016 at 18:14, Julien Grall <julien.grall@xxxxxxx> wrote:
> > > > > > On 24/11/16 21:10, Volodymyr Babchuk wrote:
> > I don't follow your point here. Why would the SMC handler need to map the
> > guest memory?
> Because this is how parameters are passed. We can pass some parameters
> in registers, but for example in OP-TEE registers hold only address of
> command buffer. In this command buffer there are actual parameters.
> Some of those parameters can be references to another memory objects.
> So, to translate IPAs to PAs we need to map this command buffer,
> analyze it and so on.
So the SMC issued will contain a PA of a page belonging to the guest or Xen?

> > > > > I can see only one benefit there - this code will be not in
> > > > > hypervisor. And there are number of drawbacks:
> > > > >
> > > > > Stability: if this userspace demon will crash or get killed by, say,
> > > > > OOM, we will lose information about all opened sessions, mapped shared
> > > > > buffers, etc.That would be complete disaster.
> > > >
> > > >
> > > > I disagree on your statement, you would gain in isolation. If your
> > > > userspace
> > > > crashes (because of an emulation bug), you will only loose access to TEE
> > > > for
> > > > a bit. If the hypervisor crashes (because of an emulation bug), then you
> > > > take down the platform. I agree that you lose information when the
> > > > userspace
> > > > app is crashing but your platform is still up. Isn't it the most
> > > > important?
> > > This is arguable and depends on what you consider more valuable:
> > > system security or system stability.
> > > I'm standing on security point.
> >
> > How handling SMC in the hypervisor would be more secure? The OP-TEE support
> > will introduce code will need to:
> >         - Whitelist SMC call
> >         - Altering SMC call to translate an IPA to PA
> >         - Keep track of session
> >         - ....
> > In general, I am quite concern every time someone ask to add emulation in
> > the hypervisor.  This is increasing the possibility of bug, this is more
> > true with emulation.
> It is not an emulation. Actually it is virtualization. It is like
> hypervisor provides virtual CPU or virtual GIC. There can be virtual
> TEE as well.
We seem to be disagree on terminology here. The virtualization is a 
generic term for creating a virtual resource. This could be done by the 
hardware or by software (aka emulation).
In the case of the GIC, we use both:
        - emulation for the distributor
        - HW-assisted for the CPU interface

In your case, you need to mangle the SMC parameters so this is software 
virtualization (aka emulation).
[...]

> > I am not saying this is the best way, but I think we should explore more
> > before saying: "Let's put more emulation in the hypervisor". Because here we
> > are not talking about one TEE, but potentially multiple ones.
> Yep. I'm not convinced yet to use separate VM. But lets try to image
> how it will look.
>
> Someone (can we trust dom0?) should identity which TEE is running on
> system and create service domain with appropriate TEE handler.
> There will be problem if we are using Secure Boot. Bootloader (like
> ARM Trusted FW) can verify XEN in Dom0 kernel images. But it can't
> verify which TEE handler will be loaded into service domain. This
> verification can be done only by dom0, so dom0 userspace should be
> part of chain of trust. This imposes restrictions on dom0 structure.
>
> Then, when it comes to SMC call from guest. there should be special
> subsystem in hypervisor. It will trap SMC, put all necessary data into
> ring buffer and issue event to service domain. Probably, we will need
> some hypercall to register service domain as SMC handler. But again,
> how we can trust to that domain? Probably dom0 will say "use domain N
> as trusted SMC handler"
>
> Anyway, service domain handles SMC (probably, by doing real SMC to
> TEE) and uses the same ring buffer/event channel mechanism to return
> data to calling guest. During SMC handling it will map guest memory
> pages by IPA, so we will need hypercall "map arbitrary guest memory by
> guest IPA".
>
> If service domain will need to wake up guest that is sleeping in TEE
> client code, it will ask hypervisor to fire interrupt to that guest.
>
> Then, I took a look onto MiniOS. Looks like it does not support
> aarch64, so it need to be ported.
>
> On other hand TEE virtualization right in hypervisor would ease things
> significantly: no problems with secure boot, trusted service domains,
> memory mapping, etc.
Let see what the other thinks.

> Also, I hate to ask again, but can we ask some TrustZone guys on how
> they see interaction between Normal and Secure worlds in presence of
> hypervisor?
This has been asked and I am waiting an answer.

Regards,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel