Re: [Xen-devel] [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 04/04/2016 09:01 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 04, 2016 at 09:00:00AM -0600, Jan Beulich wrote:
> > > > > On 24.03.16 at 21:00, <konrad.wilk@xxxxxxxxxx> wrote:
> > > @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to match 
> > > against.
> > >   The old code allows much more flexibility and an additional guard,
> > >   but is more complex to implement.
> > >
> > > +The second option which requires an build-id of the hypervisor
> > > +is implemented in the Xen Project hypervisor.
> > > +
> > > +Specifically each payload has two build-id ELF notes:
> > > + * The build-id of the payload itself (generated via --build-id).
> > > + * The build-id of the payload it depends on (extracted from the
> > > +   the previous payload or hypervisor during build time).
> > > +
> > > +This means that the very first payload depends on the hypervisor
> > > +build-id.
> > So this is mean to be a singly linked chain, not something with
> > branches and alike, allowing independent patches to be applied
> > solely based on the base build ID? Is such a restriction not going
> Correct.
> > to get in the way rather sooner than later?
> Here is what the design doc says:
>
> "
> ### xSplice interdependencies
>
> xSplice patches interdependencies are tricky.
>
> There are the ways this can be addressed:
>   * A single large patch that subsumes and replaces all previous ones.
>     Over the life-time of patching the hypervisor this large patch
>     grows to accumulate all the code changes.
>   * Hotpatch stack - where an mechanism exists that loads the hotpatches
>     in the same order they were built in. We would need an build-id
>     of the hypevisor to make sure the hot-patches are build against the
>     correct build.
>   * Payload containing the old code to check against that. That allows
>     the hotpatches to be loaded indepedently (if they don't overlap) - or
>     if the old code also containst previously patched code - even if they
>     overlap.
>
> The disadvantage of the first large patch is that it can grow over
> time and not provide an bisection mechanism to identify faulty patches.
>
> The hot-patch stack puts stricts requirements on the order of the patches
> being loaded and requires an hypervisor build-id to match against.
>
> The old code allows much more flexibility and an additional guard,
> but is more complex to implement.
>
> The second option which requires an build-id of the hypervisor
> is implemented in the Xen Project hypervisor.
>
> "
>
> I was all for "old_code to check against" but that would incur quite a lot
> of implementation. The 'stacking' (suggested by Martin) is much easier
> to implement. I am hoping that in next major milestone the 'old code' checking
> can be implemented such that the admin has the choice to use both.
I don't think checking old code provides any real safety though. What if 
the function I'm replacing is unchanged (so it passes the old code 
check) but it calls some other function whose behavior has changed?
It's somewhat telling that the publicly available binary patches for 
kSplice always use a linear stack of patches with dependency management 
done in userspace, despite having old code checking. What kSplice use in 
practice is exactly what is implemented here; a linear stack of patches 
using some sort of identifier (build-id/uuid).
--
Ross Lagerwall

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