Re: Kexec and libxenctlr.so

[Jürgen Groß <jgross@xxxxxxxx>]

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.

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.


Juergen