Re: Kexec and libxenctlr.so

[Julien Grall <julien@xxxxxxx>]

Hi Juergen,

On 12/06/2020 05:25, Jürgen Groß wrote:
> On 11.06.20 18:00, Julien Grall wrote:
> > On 11/06/2020 16:35, Jürgen Groß wrote:
> > > On 11.06.20 17:27, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 11/06/2020 16:21, Jürgen Groß wrote:
> > > > > On 11.06.20 16:57, Julien Grall wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > kexec-tools has an option to load dynamically libxenctlr.so (not 
> > > > > > .so.4.x) (see [1]).
> > > > > > Given that the library has never been considered stable, it is 
> > > > > > probably a disaster that is waiting to happen.
> > > > > > Looking at the tree kexec is using the follow libxc functions:
> > > > > >     - xc_kexec_get_range()
> > > > > >     - xc_kexec_load()
> > > > > >     - xc_kexec_unload()
> > > > > >     - xc_kexec_status()
> > > > > >     - xc_kexec_exec()
> > > > > >     - xc_version()
> > > > > >     - xc_interface_open()
> > > > > >     - xc_interface_close()
> > > > > >     - xc_get_max_cpus()
> > > > > >     - xc_get_machine_memory_map()
> > > > > >
> > > > > > I think it is uncontroversial that we want a new stable library 
> > > > > > for all the xc_kexec_* functions (maybe libxenexec)?
> > > > > > However I am not entirely sure where to put the others.
> > > > > >
> > > > > > I am thinking to introduce libxensysctl for xc_get_max_cpus() as 
> > > > > > it is a XEN_SYSCTL. We could possibly include 
> > > > > > xc_get_machine_memory_map() (despite it is a XENMEM_).
> > > > > > For xc_version(), I am thinking to extend libxentoolcore to also 
> > > > > > include "stable xen API".
> > > > > > Any opinion on the approach?
> > > > > You could consider hypfs (at least for some of the functionality).
> > > > That would work!
> > > >
> > > > > xc_version() and xc_get_max_cpus() would be rather easy.
> > > > I am guessing we will need a fallback to the normal hypercalls if 
> > > > hypfs is not present.
> > > Or we don't support kexec-tools running on a system without hypfs
> > > (or the related functions would return an error on those systems).
> > AFAICT, hypfs allows you to modify runtime parameters which is not 
> > required for kexec.
> Well, and? kexec won't use this functionality.
>
> libxenctrl allows to create domains, which isn't required for kexec.
> And kexec doesn't do it.
And so does libc... so that was clear not my point...

> We could still have the entry points for that functionality in
> libxenexec, which could use libxenhypfs (and maybe others).
>
> > Such feature could be undesirable in some setup and therefore I don't 
> > think this is acceptable to impose that for kexec.
> If we really have setups where this would be an issue we'd need
> to modify the flask integration of hypfs to be able to disallow
> write access to hypfs. Or we could even add per-node access rights.
... Not everyone wants to use flask and I don't think this should be a 
condition to forbid runtime configuration change for all the system.
You may want to set a minimal Xen with no runtime configuration support 
and no flask. Yet you may want to kexec for updating your Xen.
Even with the runtime bits removed, I still don't think we should impose 
to build hypfs in the hypervisor given there are already always built 
hypercalls.
Cheers,

--
Julien Grall