Re: [ARM] Native application design and discussion (I hope)

[Stefano Stabellini <sstabellini@kernel.org>]

On Fri, 21 Apr 2017, Julien Grall wrote:
> Hi Volodymyr,
> 
> On 21/04/17 18:04, Volodymyr Babchuk wrote:
> > On 21 April 2017 at 19:47, Julien Grall <julien.grall@arm.com> wrote:
> > > On 21/04/17 17:16, Volodymyr Babchuk wrote:
> > > > On 21 April 2017 at 18:57, Julien Grall <julien.grall@arm.com> wrote:
> > > > > 
> > > > > Hello Volodymyr,
> > > > > 
> > > > > On 20/04/17 21:20, Volodymyr Babchuk wrote:
> > > > > > 
> > > > > > 
> > > > > > On 12 April 2017 at 22:17, Stefano Stabellini
> > > > > > <sstabellini@kernel.org>
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, 12 Apr 2017, Dario Faggioli wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Tue, 2017-04-11 at 13:32 -0700, Stefano Stabellini wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Fri, 7 Apr 2017, Stefano Stabellini wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > We would have one app per emulator. Each app would register an
> > > > > > > MMIO
> > > > > > > range or instruction set to emulate. On a guest trap, Xen figures
> > > > > > > out
> > > > > > > which app it needs to run.
> > > > > > 
> > > > > > 
> > > > > > I't is not best approach, I think. For example we need one SMC
> > > > > > handler
> > > > > > for
> > > > > > all domains. Because that SMC handler should track execution state
> > > > > > of
> > > > > > different
> > > > > > guests to help TEE with scheduling. You know, TEE can't block in
> > > > > > secure
> > > > > > state,
> > > > > > so it returns back and blocks in kernel driver. SMC handler need to
> > > > > > know
> > > > > > which guest it needs to wake up when times comes.
> > > > > > 
> > > > > > The same story with virtual coprocessors, I think.
> > > > > > 
> > > > > > On other hand, MMIO handler can be one per domain. So, it should be
> > > > > > configurable. Or, maybe we need per-app MMIO handler and one global
> > > > > > SMC
> > > > > > handler.
> > > > > > Perhaps, we need to think about all possible use cases.
> > > > > 
> > > > > 
> > > > > 
> > > > > Could you explain what would be the benefits to run this global SMC
> > > > > handler
> > > > > in EL0?
> > > > > 
> > > > > After all, it will require access to the host SMC. So what will you
> > > > > protect
> > > > > against?
> > > > 
> > > > Yes, it will require access to host SMC. Idea is not to protect (but,
> > > > it can protect also).
> > > > I want to allow different guests to work with one TEE. Imagine that
> > > > multiple guests need
> > > > protected storage, accelerated cryptography or other TEE services.
> > > > All SMCs will be trapped to app, app will alter(or block) request and
> > > > forward it to TEE. This is the most basic use case, which we want to
> > > > implement.
> > > 
> > > 
> > > I am sorry, but I don't understand it. I envision EL0 as a way to limit
> > > the
> > > attack vector to Xen and the host. If you give full access to SMC, then
> > > you
> > > cannot protect.
> > In any case it will limit the attack surface. Filtered SMC request is
> > not as destructive as
> > arbitrary SMC from a guest.
> 
> I agree with that. But why in EL0? I think you answer partly below.
> 
> > 
> > > If the idea is not to protect, why do you want to move the code in EL0?
> > > What
> > > is the point to add an overhead (even if it is small) in this case?
> > There are many reasons:
> > 1. Community is reluctant to add OP-TEE (or any other TEE) handler
> > right into hypervisor codebase.
> 
> Well, I think I was the only one to be reluctant. And I asked you to look at
> different solutions and come up with suggestion are saying why you solution is
> better.
> 
> Whilst I agree that EL0 app is a solution for a lot of emulation. We should be
> careful before moving code to EL0 and evaluating the impact. I am expecting to
> see the interface very small and the application to be standalone (e.g not
> requiring much interaction with Xen or the host hardware).

I also had this understanding


> But you seem to have a different view (see your e-mail with:
> "Probably, we can try another approach: allow application to register
> hooks in hypervisor: i.e. hook on MMIO, hook on SMC, hook on timer and
> so on.").
> 
> If you introduce EL0 but require a big interface, then I believe you don't
> limit the surface attack.

Also, it is difficult to maintain a large EL0-Xen interface.

The idea is basically to register an MMIO range to emulate, submit the
request to the EL0 app, which would take care of the emulation. The
interface with Xen would be mostly limited to map/unmap guest memory
(only the guest it is servicing) and send interrupts to the guest. It
would always and only be run immediately after the guest vcpu in its own
time slot.

The key is to be simple. If it becomes complex, then we are reinventing
stubdoms.

If the workload needs hardware access, periodical scheduling and it's
only once instance for all domains, then it's probably better as a
stubdom.

If the workloads doesn't need hardware access, it's one instance per
domain, at most it needs to register a timer with Xen, then it would be
fine as EL0 app. For the EL0 app framework, I'll start from there.


For example, I can see that something as complex as TEE emulation could
have one component running as an EL0 app and another component in a
stubdom, coexisting peacefully.

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