[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC v2] xSplice design



On Fri, Jun 12, 2015 at 01:51:08PM +0200, Martin Pohlack wrote:
> On 08.06.2015 17:19, Konrad Rzeszutek Wilk wrote:q

Heh - ":q", well now I know what editor camp you are in :-)

> [...]
> >>> There is a nice part of the old code check - you
> >>> can check (and deal with) patching an already patched code.
> >>> As in, if the payload was configured to be applied on top of an already
> >>> patched function it would patch nicely. But if the payload is against
> >>> the virgin code - and the hypervisor is running an older patch, we would
> >>> bail out.
> >>
> >> You can do that too with the build IDs if there is some mechanism that
> >> loads hotpatches in the same order as they were built in (if they
> >> overlap).  The simplest approach that comes to mind is a hotpatch stack,
> >> instead of independent patches.
> > 
> > True. Murphy law though says somebody will do this in reverse order :-)
> > And that is my worry - some system admin will reverse the order, or pick
> > an patch out of order, and we end up patching .. and things eventually
> > break and blow up.
> 
> Right, I can see how this might be useful as an additional guard.
> 
> There are some additional benefits to using build IDs, beyond preventing
> loading patches for the wrong hypervisor.  They can also help locate
> patches for the currently running hypervisor if laid out correspondingly
> on disk, e.g.:
> 
>   /some/path/<build_ID>/nnnnn-patch1.mod
> 
> A userland tool would query for the specific build ID of the currently
> running hypervisor and only attempt to load hotpatches designated for
> it.  This is a stronger protection than relying on the RPM version or a
> similar mechanism.
> 
> * build ID
>   * Prevent loading of wrong hotpatches (intended for other builds)
>   * Allow to identify suitable hotpatches on disk and help with runtime
>     tooling (if laid out using build ID)
> 
> * Comparing old code
>   * Prevent loading of dynamically incompatible hotpatches

<nods> Having them both sounds sensible.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.