From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Martin Pohlack <mpohlack@amazon.com>
Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>,
jeremy@goop.org, hanweidong@huawei.com, jbeulich@suse.com,
john.liuqiming@huawei.com,
Paul Voccio <paul.voccio@rackspace.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Major Hayden <major.hayden@rackspace.com>,
liuyingdong@huawei.com, aliguori@amazon.com,
xiantao.zxt@alibaba-inc.com, lars.kurth@citrix.com,
Steven Wilson <steven.wilson@rackspace.com>,
peter.huangpeng@huawei.com, msw@amazon.com,
xen-devel@lists.xenproject.org,
Rick Harris <rick.harris@rackspace.com>,
boris.ostrovsky@oracle.com,
Josh Kearney <josh.kearney@rackspace.com>,
jinsong.liu@alibaba-inc.com,
Antony Messerli <amesserl@rackspace.com>,
konrad@darnok.org, fanhenglong@huawei.com,
andrew.cooper3@citrix.com
Subject: Re: [RFC v2] xSplice design
Date: Fri, 12 Jun 2015 10:06:08 -0400 [thread overview]
Message-ID: <20150612140608.GH15651@l.oracle.com> (raw)
In-Reply-To: <557AC7AC.8050902@amazon.com>
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.
next prev parent reply other threads:[~2015-06-12 14:06 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 19:44 [RFC v2] xSplice design Konrad Rzeszutek Wilk
2015-05-18 12:41 ` Jan Beulich
2015-06-05 14:49 ` Konrad Rzeszutek Wilk
2015-06-05 15:16 ` Jan Beulich
2015-06-05 16:00 ` Konrad Rzeszutek Wilk
2015-06-05 16:14 ` Jan Beulich
2015-05-18 12:54 ` Liuqiming (John)
2015-05-18 13:11 ` Daniel Kiper
2015-06-05 14:50 ` Konrad Rzeszutek Wilk
2015-05-19 19:13 ` Lars Kurth
2015-05-20 15:11 ` Martin Pohlack
2015-06-05 15:00 ` Konrad Rzeszutek Wilk
2015-06-05 15:15 ` Andrew Cooper
2015-06-05 15:27 ` Jan Beulich
2015-06-08 8:34 ` Martin Pohlack
2015-06-08 8:51 ` Jan Beulich
2015-06-08 14:38 ` Martin Pohlack
2015-06-08 15:19 ` Konrad Rzeszutek Wilk
2015-06-12 11:51 ` Martin Pohlack
2015-06-12 14:06 ` Konrad Rzeszutek Wilk [this message]
2015-06-12 11:39 ` Martin Pohlack
2015-06-12 14:03 ` Konrad Rzeszutek Wilk
2015-06-12 14:31 ` Martin Pohlack
2015-06-12 14:43 ` Jan Beulich
2015-06-12 17:31 ` Martin Pohlack
2015-06-12 18:46 ` Konrad Rzeszutek Wilk
2015-06-12 16:09 ` Konrad Rzeszutek Wilk
2015-06-12 16:17 ` Andrew Cooper
2015-06-12 16:39 ` Konrad Rzeszutek Wilk
2015-06-12 18:36 ` Martin Pohlack
2015-06-12 18:51 ` Konrad Rzeszutek Wilk
2015-07-06 19:36 ` Konrad Rzeszutek Wilk
2015-10-27 12:05 ` Ross Lagerwall
2015-10-29 16:55 ` Ross Lagerwall
2015-10-30 10:39 ` Martin Pohlack
2015-10-30 14:03 ` Ross Lagerwall
2015-10-30 14:06 ` Martin Pohlack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150612140608.GH15651@l.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=aliguori@amazon.com \
--cc=amesserl@rackspace.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=daniel.kiper@oracle.com \
--cc=elena.ufimtseva@oracle.com \
--cc=fanhenglong@huawei.com \
--cc=hanweidong@huawei.com \
--cc=jbeulich@suse.com \
--cc=jeremy@goop.org \
--cc=jinsong.liu@alibaba-inc.com \
--cc=john.liuqiming@huawei.com \
--cc=josh.kearney@rackspace.com \
--cc=konrad@darnok.org \
--cc=lars.kurth@citrix.com \
--cc=liuyingdong@huawei.com \
--cc=major.hayden@rackspace.com \
--cc=mpohlack@amazon.com \
--cc=msw@amazon.com \
--cc=paul.voccio@rackspace.com \
--cc=peter.huangpeng@huawei.com \
--cc=rick.harris@rackspace.com \
--cc=steven.wilson@rackspace.com \
--cc=xen-devel@lists.xenproject.org \
--cc=xiantao.zxt@alibaba-inc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).