Re: [RFC v2] xSplice design

[Martin Pohlack <mpohlack@amazon.com>]

On 08.06.2015 17:19, Konrad Rzeszutek Wilk wrote:q
[...]
>>> 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

Martin