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

[Julien Grall <julien.grall@xxxxxxx>]

(CC tools maintainers)

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


> 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.
I would rather avoid to take this approach until we explored all the 
possibility.
We took this approach for platform device passthrough because we 
considered it would only be used for embedded platform where everything 
will be under control.
In the case of virtual co-processor, I can see a usage beyond embedded 
so we would need to deal with non-trusted input.
> > > 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?
The tools are here to provide a nice and comprehensible interface 
between Xen and the user. At the end the hypervisor is in charge of 
creating a domain, handling the memory...
Dom0 may have restrict access to the guest, but the hypervisor does not 
have such restriction. So if you compromise the hypervisor you 
compromise the whole platform.
> > 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.
No, the vGIC only needs to know the maximum number of interrupts it can 
handle. You don't need to route them at that time.
Currently, the toolstack is deciding on the number of spis supported 
(give a look at nr_spis).
IHMO, the toolstack should be able to figure out the number of 
interrupts required by the virtual co-processors and then update nr_spis 
accordingly.
> > this should be done later on.
> What is the proper moment to spawn virtual coprocessors for guest
> domains from your point of view?
The DOMCTL createdomain does not scale for things like co-processors. It 
is only here to initialize the bare minimum for a domain. You could 
create new DOMCTL to handle co-processors and call them afterwards from 
libxl__arch_domain_create.
Cheers,

--
Julien Grall

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