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

[Volodymyr Babchuk <vlad.babchuk@xxxxxxxxx>]

Julien,

On 21 April 2017 at 19:47, Julien Grall <julien.grall@xxxxxxx> wrote:
> On 21/04/17 17:16, Volodymyr Babchuk wrote:
>>
>> Hi Julien,
>
>
> Hi Volodymyr,
>
>
>> On 21 April 2017 at 18:57, Julien Grall <julien.grall@xxxxxxx> wrote:
>>>
>>> Hello Volodymyr,
>>>
>>> On 20/04/17 21:20, Volodymyr Babchuk wrote:
>>>>
>>>>
>>>> On 12 April 2017 at 22:17, Stefano Stabellini <sstabellini@xxxxxxxxxx>
>>>> 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.

> 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.
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).
3. Some degree of protection. Bug in EL0 handler will not bring down
whole hypervisor.

Andrii can correct me, but the same reasons apply to virtual
coprocessors framework and drivers.

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

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