[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v1 01/11] xsplice: Design document (v2).

On 11/04/2015 09:10 PM, Konrad Rzeszutek Wilk wrote:
+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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.