From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC v2] xSplice design Date: Mon, 8 Jun 2015 11:19:45 -0400 Message-ID: <20150608151945.GO15682@l.oracle.com> References: <20150515194440.GA24313@l.oracle.com> <555CA418.6080707@amazon.com> <20150605150029.GC10207@l.oracle.com> <5575A8F7.3070006@amazon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z1yqh-0006PV-Gd for xen-devel@lists.xenproject.org; Mon, 08 Jun 2015 15:20:27 +0000 Content-Disposition: inline In-Reply-To: <5575A8F7.3070006@amazon.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Martin Pohlack Cc: Elena Ufimtseva , jeremy@goop.org, hanweidong@huawei.com, jbeulich@suse.com, john.liuqiming@huawei.com, Paul Voccio , Daniel Kiper , Major Hayden , liuyingdong@huawei.com, aliguori@amazon.com, xiantao.zxt@alibaba-inc.com, lars.kurth@citrix.com, Steven Wilson , peter.huangpeng@huawei.com, msw@amazon.com, xen-devel@lists.xenproject.org, Rick Harris , boris.ostrovsky@oracle.com, Josh Kearney , jinsong.liu@alibaba-inc.com, Antony Messerli , konrad@darnok.org, fanhenglong@huawei.com, andrew.cooper3@citrix.com List-Id: xen-devel@lists.xenproject.org . snip .. > >> * You may need support for adapting or augmenting exception tables if > >> patching such code is desired (it probably is). Hotpatches may need > >> to bring their own small exception tables (similar to how Linux > >> modules support this). If you don't plan on supporting hotpatches > >> that introduce additional exception-locations, one could also change > >> the exception table in-place and reorder it afterwards. > > > > Each patch carries 'section' structures which define what kind > > of massaging needs to be done. As in each of these 'section' structues > > says: > > - At the original address X there was an excetion table > > - (or) At the origian address Y there was an alt assembler > > > > And we would: > > - During 'check' state, confirm that indeed X is in the exception table > > (or Y in the alt assembler) > > > > - During the apply state, fix the exception table X offset to point to > > the new virtual address. > > > > Or perhaps I am over-simplying it? My recollection of the exception > > table code is that it would be mostly dealing with the table and > > changing the virtual address, but I hadn't dug it in details. > > A simple approach would indeed be to patch the table in-place with the > new addresses for the replacement functions and fix-up sections. But, > you would also have to reorder the table to keep the binary search working. > > And of course this approach would not support adding additional entries > to the table as it is allocated at compile / link time. So you cannot > support a hotpatch that would introduce an additional entry. > > Linux modules, in contrast can bring their own exception tables and > those are walked by the handler whenever the main table does not contain > an entry. I have not implemented that aspect yet, but would consider > this to be the most desirable design upon first look. It is in some way an implementation part. I will include it in the doc as there are many parts here and having them all nicely outlined makes my head spin less. .. snip.. > >>> > >>> We must also have a mechanism to: provide an copy of the old code - so that > >>> the hypervisor can verify it against the code in memory; the new code; > >> > >> As Xen has no stable in-hypervisor API / ABI, you need to make sure > >> that a generated module matches a target hypervisor. In our design, > >> we use build IDs for that (ld --build-id). We embed build IDs at Xen > >> compile time and can query a running hypervisor for its ID and only > >> load matching patches. > >> > >> This seems to be an alternative to your proposal to include old code > >> into hotpatch modules. > > > > That is much simpler. > > Just to clarify, are you agreeing that the build ID approach is much > simpler? Yes. > > > 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.