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