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

[Volodymyr Babchuk <vlad.babchuk@gmail.com>]

Hi Julien,

On 21 April 2017 at 20:38, Julien Grall <julien.grall@arm.com> 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.
Yes.

>>
>>> 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.
Frankly, I'll be glad to put TEE handler right into the hypervisor. It
will ease up a lot
of things.

> 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). 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.
Yes, actually we see EL0 apps as a way to extend hypervisor in a some
manageable way.
Isolation is a bonus. We here, at EPAM want to use EL0 apps for two things:
1. TEE support
2. vcoproc drivers.
Also apps can be used for
3. Device emulation (PL011 is the obvious candidate).

Obviously, 1 and 2 are not safe by their nature, even if they can be
executed in EL0.
In this cases apps can provide only modularity. And we will be happy to put them
right into hypervisor, if there are no objections.

>> 2. Modularity. You can detect running TEE during boot and load
>> appropriate TEE handler app (honestly, it is not a big deal, because
>> you know on which system will work your hypervisor and TEE type can be
>> hardcoded in build).
>
> Well, you could make Xen modular like Linux and still run everything in EL2.
> (Disclaimer, I am not saying we should do that...)
Yes, we could. And this will be a lot faster, than to run something in EL0.
This approach has own benefit: it will be crossplatform feature.

>> 3. Some degree of protection. Bug in EL0 handler will not bring down
>> whole hypervisor.
> If you have a single app handling all the domains using SMC, then you will
> bring down all thoses domains. I agree it does not take down the hypervisor,
> but it will render unusable a part of the platform.
This will bring down TEE interface, right. Domains will lose ability
to communicate
with TEE, but other functionality will remain intact.

> In this case, how do you plan to restore the services?
The obvious solution is to reboot the whole platform. It will be more
controlled process, than hypervisor crash.
But there are more soft ways.

For example, SMC app can be restarted. Then, I am almost sure that I
can ask OP-TEE to abort all opened sessions. After that, requests from
a new domains can be processed as usual, but we can't rely on state of
old domains, so they should be gracefully restarted. There will be
problem with dom0/domD, though.

> Also, a bug in the EL0 handler may give the opportunity, in your use case,
> to get access to the firmware or data from another guest. How this will
> bring more protection?
On other hand, bug in EL2 handler will give access to whole supervisor.

> If you handle only one guest per app, then it is very easy to kill that app
> and domain. It will only harm itself.
Yes, I agree. It is great for emulators (and can be used it this
case). But, unfortunately, TEE handler needs shared state. I can't see
how to implement OP-TEE handler without shared knowledge about wait
queues in all guests.

It just came to me that it can be possible to move most of this stuff
to OP-TEE. Can S-EL1 request two stage table walk for a given guest?
We can do this in software, anyways. Probably I can minimize TEE
handler it hypervisor, make it almost generic. Need to think more
about this...

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babchuk@gmail.com

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