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

[Julien Grall <julien.grall@xxxxxxx>]

On 05/05/2017 04:27 PM, Andrii Anisov wrote:
> 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.
The code is not set in stone. It can be reworked to avoid that.

> > 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.
Passing an fdt blob to the hypervisor should be used at the last resort. 
Whilst I agree it would be difficult to get a suitable interface between 
the user and the toolstack, C allows a lot of freedom to create suitable 
structure. So I still don't understand why you want to use a device tree 
between the toolstack and the hypervisor.
Cheers,

--
Julien Grall

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