From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Lagerwall Subject: Re: [PATCH v1 01/11] xsplice: Design document (v2). Date: Thu, 5 Nov 2015 10:49:51 +0000 Message-ID: <563B344F.80109@citrix.com> References: <1446574568-9644-1-git-send-email-ross.lagerwall@citrix.com> <20151104211038.GC16253@char.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20151104211038.GC16253@char.us.oracle.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: Konrad Rzeszutek Wilk Cc: Tim Deegan , Ian Jackson , Ian Campbell , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 11/04/2015 09:10 PM, Konrad Rzeszutek Wilk wrote: snip >> +The payload **MUST** contain enough data to allow us to apply the update >> +and also safely reverse it. As such we **MUST** know: >> + >> + * The locations in memory to be patched. This can be determined dynamically >> + via symbols or via virtual addresses. >> + * The new code that will be patched in. >> + * Signature to verify the payload. > > Argh. We need to move the 'Signature to verify' in the 'v2' section > as I don't think we can get that done in time. No, not for V1. > >> + >> +This binary format can be constructed using an custom binary format but >> +there are severe disadvantages of it: >> + >> + * The format might need to be changed and we need an mechanism to accommodate >> + that. >> + * It has to be platform agnostic. >> + * Easily constructed using existing tools. >> + >> +As such having the payload in an ELF file is the sensible way. We would be >> +carrying the various sets of structures (and data) in the ELF sections under >> +different names and with definitions. The prefix for the ELF section name >> +would always be: *.xsplice* to match up to the names of the structures. >> + >> +Note that every structure has padding. This is added so that the hypervisor >> +can re-use those fields as it sees fit. >> + >> +Earlier design attempted to ineptly explain the relations of the ELF sections >> +to each other without using proper ELF mechanism (sh_info, sh_link, data >> +structures using Elf types, etc). This design will explain in detail >> +the structures and how they are used together and not dig in the ELF >> +format - except mention that the section names should match the >> +structure names. >> + >> +The xSplice payload is a relocatable ELF binary. A typical binary would have: >> + >> + * One or more .text sections >> + * Zero or more read-only data sections >> + * Zero or more data sections >> + * Relocations for each of these sections >> + >> +It may also have some architecture-specific sections. For example: >> + >> + * Alternatives instructions >> + * Bug frames >> + * Exception tables >> + * Relocations for each of these sections >> + >> +The xSplice core code loads the payload as a standard ELF binary, relocates it >> +and handles the architecture-specifc sections as needed. This process is much >> +like what the Linux kernel module loader does. It contains no xSplice-specific >> +details and thus will not be discussed further. > > What is 'it'? The 'process of what module loader does'? 'It' refers to the process of module loading in the previous sentence. > >> + >> +Importantly, the payload also contains a section with an array of structures >> +describing the functions to be patched: >> +
>> +struct xsplice_patch_func {
>> +    unsigned long new_addr;
>> +    unsigned long new_size;
>> +    unsigned long old_addr;
>> +    unsigned long old_size;
>> +    char *name;
>> +    uint8_t pad[64];
>> +};
>> +
>
> Uh, so 104 bytes ? Or did you mean to s/64/24/ so the structure is nicely
> padded to 64-bytes?
>
> I think that is what you meant.

OK. I'm not too fussed about exact sizes for V1 anyway, it's likely to 
change at some point.

-- 
Ross Lagerwall