[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] scf: SCF device tree and configuration documentation



Julien,


On 04.05.17 15:46, Julien Grall wrote:

I understand these concerns, but not sure should we be scared of attack
from a domain privileged enough to run domains?

Whilst the domain is privileged enough to run domains, the configuration can be provided by a user (for instance in cloud environment). So you cannot trust what the user provided and any missing invalidation would lead to a security issue (see XSA-95 [1] for instance).

That's why we specifically said only trusted device tree should be used with the option "device_tree".
I see. But I also could state the same.

It seems to me that system hypervisor attack through libfdt is the less
valuable benefit from compromised dom0.

It is much more valuable, DOM0 may still have limited access to functionally whilst the hypervisor has access to everything.
Well, from dom0 you could start/stop any domain you want, grant access to any hardware, but only from hypervisor you could map another domain memory to access some runtime data. Is my understanding correct?

Also, I do believe that the domain creation should be limited to create the domain and not configuring the devices other than the strict necessary. For anything else (UART, co-processor),
But vgic is configured at the earliest stages of the domain creation. So we have to know at the moment which IRQs would be injected into the domain. And that is my current problem.

this should be done later on.
What is the proper moment to spawn virtual coprocessors for guest domains from your point of view?

--

*Andrii Anisov*



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.