Re: [Tee-dev] TEE with XEN

[Bertrand Marquis <Bertrand.Marquis@arm.com>]

> On 18 Jun 2020, at 23:17, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> On Thu, 18 Jun 2020, Julien Grall wrote:
>> +Bertrand and Stefano
> 
> Thanks for CC'ing me
> 
> 
>> On 16/06/2020 02:24, Volodymyr Babchuk wrote:
>>> Hi Peng,
>>> 
>>> On Mon, 15 Jun 2020 at 05:07, Peng Fan <peng.fan@nxp.com> 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?
>> 
>>>> 
>>>> 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).
> 
> Given that Secure World has access to Normal World but not vice versa,
> it is more natural to run Trusty in one of the Secure execution levels.
> The expectation is that Trusty has higher privilege, thus it is more
> "trusted" than anything running in Normal World, including Xen.
> 
> Of course no client should be able to crash Trusty, so the reality
> sometimes can be very different from the theory :-)
> 
> If I were you, I would consider running the TEE "inside" the VM only if
> the service that the TEE provides is strongly coupled with the VM and
> doesn't actually need a high level of privilege to function (i.e.
> doesn't access secure devices or at least not often.)
> 

I could see some scenarios where this would make sense if you trust one VM more then an other.
But this falls into a model of “virtualizing” optee using a VM where from the system point of view any usage of this VM from the functionality could not be more trusted then Xen And the VM providing the service.

> 
>> 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.
> 
> This would most probably be the best compromise.

Agree.

Bertrand