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

[Andrii Anisov <andrii_anisov@xxxxxxxx>]

Hello Julien,

On 05.05.17 17:12, Julien Grall wrote:
> (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.
Yep, it's one of our targets to spread SCF beyond the embedded world.
> > > 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 will lead to the need of parse (and maybe reads dtb file) first 
here. Then one more time on DomU device tree generation.
> > > 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.
It is done in such way now. From libxl__arch_domain_create another 
domctl sends a pfdt blob to hypervisor for SCF configuration.
--

*Andrii Anisov*

*
*


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