Difference between revisions of "LivePatch"

From Xen
(Hypervisor)
(Hypervisor)
Line 46: Line 46:
 
Oct-12-2015: Konrad posted v1 patchset. Needs rework.
 
Oct-12-2015: Konrad posted v1 patchset. Needs rework.
 
* Need 'dl_sym' functionality in hypervisor to parse ELF payload. Do dynamic linking. (Ross)
 
* Need 'dl_sym' functionality in hypervisor to parse ELF payload. Do dynamic linking. (Ross)
* Lookup and insertion in the symbol table. Compute the proper offset and virtual address
+
* Lookup and insertion in the symbol table. Compute the proper offset and virtual address based on symbol name (<do_domctl>+0xf) (Ross)
based on symbol name (<do_domctl>+0xf) (Ross)
 
 
* Need to either remove duplicate names from the symbol table or have the hypervisor implement proper ELF parsing - integrate the elf sections and parse that during runtime.
 
* Need to either remove duplicate names from the symbol table or have the hypervisor implement proper ELF parsing - integrate the elf sections and parse that during runtime.
 
* Insertion of exceptions in the exception table. Also support resorting it. The hot-patch may have new exceptions that need to be dealt with.
 
* Insertion of exceptions in the exception table. Also support resorting it. The hot-patch may have new exceptions that need to be dealt with.

Revision as of 13:23, 12 October 2015

Design

xSplice RFC v3.1 design Xsplice v1 design

On August 18th @11:30 - 12:20 in Seattle will nail down in person some of the questions raised on xen-devel mailing list.Done - code has been updated to include resolution on that.

The git code for hypervisor/toolstack currently is at:

git://xenbits.xen.org/people/konradwilk/xen.git #xsplice.v1.1

The generation of payload is at:

https://github.com/rosslagerwall/xsplice-build

IRC

We will have monthly IRC meetings to discuss code/issues/etc.

They are on the fourth Monday of every month. At 10:00AM EST on #xsplice channel on irc.freenode.net

Toolstack

Things that need to be done in there:

  • xen-xsplice better smarts. Right now you need to do 'upload','check' and 'apply'. Three operations which could be folded in one - since the system admin probably want to have all of those done at once. The 'all' option does that.
  • Instead of using 'xen-xsplice' we should use 'xl'. That above mentioned logic could be part of 'xl' while 'xen-xsplice' is an accessory function for expert users?

Build

  • Compile Xen hypervisor with -ffunction-sections. (Ross)
 Oct 12 2015: "
 I've created a _prototype_ tool for this based on kpatch's tooling. It's
 currently living at https://github.com/rosslagerwall/xsplice-build
 With no source patch modifications, live patches can be built for every XSA
 that applies to x86 back to XSA-90 except for XSA-97, XSA-111, XSA-112, and
 XSA-114 (83% success rate). It gives plausible output for each generated patch
 although I obviously can't verify the live patches yet.
 It doesn't really follow the design in the above document; IMO the payload
 design is unnecessarily complicated. At this point I'd rather just get a
 complete working prototype, and we can figure out the specifics and finalize
 the design later."

Hypervisor

We need to expand the hypervisor to include support for:

  • build_id support (done!)
 Oct-12-2015: Konrad posted v1 patchset. Needs rework.
  • Need 'dl_sym' functionality in hypervisor to parse ELF payload. Do dynamic linking. (Ross)
  • Lookup and insertion in the symbol table. Compute the proper offset and virtual address based on symbol name (<do_domctl>+0xf) (Ross)
  • Need to either remove duplicate names from the symbol table or have the hypervisor implement proper ELF parsing - integrate the elf sections and parse that during runtime.
  • Insertion of exceptions in the exception table. Also support resorting it. The hot-patch may have new exceptions that need to be dealt with.
  • Code to verify signature of the ELF payload.
  • Checking the build-id against the hypervisor.
  • Code to patch and revert the hot-patch (for simplicity we could boot Xen with 'cpus=1' so we don't have to worry about proper code to trigger patching)
    • Patching requires saving the initial state. That needs to be saved for revert.
    • Patching needs allocation of memory, putting in the code at memory.
    • Doing the verification - checking if any code that uses the to-be-patched-function is in use. Save what the virtual address for the functions is - and verify the stack when patching (this incidentally is what .xsplice_section structures can have).
    • Deal with proper page table types for the modification (ro for .data, x for .text, etc).
    • Code to revert.
  • Code to activate patching mechanism. On VMEXIT routine right before checking the do_softirq. Ditto for PV paths. Call the top patching mechanism - which can IPI other CPUs (or wait until all CPUs have come to the same point).
  • The code for doing the patching - call from __do_softirq - can also be used for runtime microcode loading.
  • Add functionality to execute ELF code.

ELF payload file

The spec details how the structures should look. We need to write tools to create this ELF file based on a header (or C code). This could be a simple as linker script magic. (Konrad wrote linker script, but the tool is primitive and a hack)

Create regression hot-patches

Need to create an .xsplice ELF payload which changes xen_extra .data structure. This way we can verify the applying and reverting of a hot-patch - and check for expected output via 'xl info' and string comparison. To make this work:

  • Write script (or C code?) which generates an ELF payload with the required changes to patch 'xen_extra'.

Build hot-patches

  • Compile Xen hypervisor where the output (.o) ends up in (.o.xsplice) to make it easier to identify changes. Could be a secondary build ('make xsplice')
  • Write in scripts/ code to compare the .o and .o.xsplice files using objcopy, diff, etc to figure out if they changed. If they do, copy the 'new' and 'old' object file as '.o.xsplice.baseline' and '.o.xsplice.new'.
  • Write tool to look for '.o.xsplice.baseline' and '.o.xsplice.new' - figure out the ELF relocations, what symbols it affects, etc. Take a hard look at objmanip.c in ksplice git tree (git://repo.or.cz/ksplice.git).
  • To start with this doing C code and injecting new code can be used as a prototype to develop.
  • Look at the 30 last XSAa and use that as a measuring stick of how well the hot-patching build works.