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

[Julien Grall <julien.grall@xxxxxxx>]

On 04/05/17 13:35, Andrii Anisov wrote:
> Hello Julien,
Hi Andrii,

> Thank you for your comments.
>
> > As you may have seen in the description of the option "device_tree",
> > it is complex to verify the partial device tree because of the libfdt
> > design. So without fully auditing libfdt and fixing the holes, this
> > suggestion would be a vector attack to the hypervisor.
> 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".
> 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.
> About a system stability issues due to libfdt holes I've just got a
> crazy idea: let us put a fdt unflatenning code into a generic EL0
> application :)
>
> > Whilst I do agree that this could be an interface between the user and
> > the toolstack, we shall look into introducing a series of DOMCTL for
> > the toolstack <-> hypervisor. What would be the issue to do that?
> There were two reasons turned me to using device tree as a configuration:
> - I did not come up with a clear and flexible enough format to describe
> a SCF configuration. Any format which would allow us describe a complex
> virtual coprocessor with several mmios and irqs, and would allow
> describe breeding for a domain several virtual coprocessors running on
> one physical coprocessor will turn to a device tree node or something
> similar. This could fit somehow the DomU configuration file, but not XEN
> command line.
> - The idea to reuse the same SCF configuration code both for Dom0 and
> DomU got me.
>
> All said above is pretty true for me, but recently I have concerned that
> once we would like to spread SCF to x86 or systems configured through
> ACPI we will have to reconsider SCF configuration again.
This is another point of the problem. 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), this should be done later on.
What I would like to understand is what are the information that the 
hypervisors as to know for sharing co-processor? So far I have:
        - MMIOs
        - Interrupts

Anything else?

Cheers,

[1] https://xenbits.xen.org/xsa/advisory-95.html

--
Julien Grall

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