[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC v2] xSplice design
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |