[Xen-devel] [PATCH v2] xSplice v1 implementation.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

Changelog (since the RFC and the Seattle Xen presentation)
 - Finished off some of the work around the build-id.
 - Settled on the preemption mechanism.
 - Cleaned the patches a lot up, broke them up to easy
   review for maintainers.
v1 (http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg02116.html)
  - Put all the design comments in the code
Prototype: 
(http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02595.html)
[Posting by Ross]
 - Took all reviews into account.
 - Redid the patches per review comments, added some extra code, etc.


*What is xSplice?*

A mechanism to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.

*What will this patchset do once I've it*

Patch the hypervisor.

*Why are you emailing me?*

Please please review the patches. The first three are the foundation of the
design and everything else depends on them.

*OK, what do you have?*

They are located at a git tree:
  git://xenbits.xen.org/people/konradwilk/xen.git xsplice.v2

There are a lot more patches after this - that implement more code
(see design document and the v2 milestone) but I do not want to
overwhelm the reviewers with 40+ patches so taking it easy and doing
it in waves.

(Copying from Ross's email):

Much of the work is implementing a basic version of the Linux kernel module
loader. The code:
* Loading of xSplice ELF payloads.
* Copying allocated sections into a new executable region of memory.
* Resolving symbols.
* Applying relocations.
* Patching of altinstructions.
* Special handling of bug frames and exception tables.
* Unloading of xSplice ELF payloads.
* Compiling a sample xSplice ELF payload (*NEW*)

The other main bit of this work is applying and reverting the patches safely.
As implemented, the code is patched with each CPU waiting in the
return-to-guest path (i.e. with no stack) or on the cpu-idle path
which appears to be the safest way of patching. While it is safe we should
still (in the next wave of patches) to verify to not patch cetain critical
sections (say the code doing the patching)

All of the following should work:
* Applying patches safely.
* Reverting patches safely.
* Replacing patches safely (e.g. reverting any applied patches and applying
   a new patch).
* Bug frames as part of modules. This means adding or
  changing WARN, ASSERT, BUG, and run_in_exception_handler works correctly.
  Line number only changes _are ignored_.
* Exception tables as part of modules. E.g. wrmsr_safe and copy_to_user work
  correctly when used in a patch module.


*Limitations*

The above is enough to fully implement an update system where multiple source
patches are combined (using combinediff) and built into a single binary
which then atomically replaces any existing loaded patches
(this is why Ross added a REPLACE operation). This is the approach used
by kPatch and kGraft.

Multiple completely independent patches can also be loaded but unexpected
interactions may occur.

As it stands, the patches are statically linked which means that independent
patches cannot be linked against one another (e.g. if one introduces a
new symbol). Using the combinediff approach above fixes this.

Backtraces containing functions from a patch module do not show the symbol name.

There is no checking that a patch which is loaded is built for the
correct hypervisor (need to use build-id). That would be done in another
"wave" of patches.

Binary patching works at the function level.

*Testing*

You can use the example code included in this patchset:

# xl info | grep extra
xen_extra              : -unstable
# xen-xsplice load /usr/lib/xen/bin/xen_hello_world.xsplice
/usr/lib/xen/bin/xen_hello_world.xsplice xen_hello_world 
/usr/lib/xen/bin/xen_hello_world.xsplice
Uploading /usr/lib/xen/bin/xen_hello_world.xsplice (2071 bytes)
Performing check: completed
Performing apply:. completed
# xl info | grep extra
xen_extra              : Hello World
# xen-xsplice revert xen_hello_world
Performing revert:. completed
# xen-xsplice unload xen_hello_world
Performing unload: completed
# xl info | grep extra
xen_extra              : -unstable


Or you can use git://github.com/rosslagerwall/xsplice-build.git tool
(it will need an extra patch, will send that shortly) - which
generates the ELF payloads.

This link has a nice description of how to use the tool:
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02595.html


Thank you for reading down to here :-)

 .gitignore                                   |    1 +
 docs/misc/xsplice.markdown                   | 1043 ++++++++++++++++++++++++
 tools/flask/policy/policy/modules/xen/xen.te |    1 +
 tools/libxc/include/xenctrl.h                |   18 +
 tools/libxc/xc_misc.c                        |  284 +++++++
 tools/misc/Makefile                          |   29 +-
 tools/misc/xen-xsplice.c                     |  475 +++++++++++
 tools/misc/xen_hello_world.c                 |   15 +
 tools/misc/xsplice.h                         |   12 +
 tools/misc/xsplice.lds                       |   11 +
 xen/arch/arm/Kconfig                         |    1 +
 xen/arch/arm/Makefile                        |    1 +
 xen/arch/arm/xsplice.c                       |   31 +
 xen/arch/x86/Kconfig                         |    1 +
 xen/arch/x86/Makefile                        |    3 +-
 xen/arch/x86/alternative.c                   |   12 +-
 xen/arch/x86/domain.c                        |    4 +
 xen/arch/x86/extable.c                       |   36 +-
 xen/arch/x86/hvm/svm/svm.c                   |    2 +
 xen/arch/x86/hvm/vmx/vmcs.c                  |    2 +
 xen/arch/x86/setup.c                         |    7 +
 xen/arch/x86/traps.c                         |   30 +-
 xen/arch/x86/xsplice.c                       |  125 +++
 xen/common/Kconfig                           |   14 +
 xen/common/Makefile                          |    3 +
 xen/common/symbols.c                         |    7 +
 xen/common/sysctl.c                          |    8 +
 xen/common/xsplice.c                         | 1089 ++++++++++++++++++++++++++
 xen/common/xsplice_elf.c                     |  285 +++++++
 xen/include/asm-arm/bug.h                    |    2 +
 xen/include/asm-arm/config.h                 |    2 +
 xen/include/asm-arm/nmi.h                    |   13 +
 xen/include/asm-x86/alternative.h            |    1 +
 xen/include/asm-x86/bug.h                    |    2 +
 xen/include/asm-x86/uaccess.h                |    5 +
 xen/include/asm-x86/x86_64/page.h            |    2 +
 xen/include/public/sysctl.h                  |  156 ++++
 xen/include/xen/elfstructs.h                 |    8 +
 xen/include/xen/kernel.h                     |    1 +
 xen/include/xen/keyhandler.h                 |    1 +
 xen/include/xen/xsplice.h                    |   63 ++
 xen/include/xen/xsplice_elf.h                |   42 +
 xen/xsm/flask/hooks.c                        |    6 +
 xen/xsm/flask/policy/access_vectors          |    2 +
 44 files changed, 3824 insertions(+), 32 deletions(-)


Konrad Rzeszutek Wilk (6):
      xsplice: Design document (v5).
      hypervisor/arm/keyhandler: Declare struct cpu_user_regs;
      xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op (v7)
      libxc: Implementation of XEN_XSPLICE_op in libxc (v4).
      xen-xsplice: Tool to manipulate xsplice payloads (v3)
      xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.

Ross Lagerwall (7):
      elf: Add relocation types to elfstructs.h
      xsplice: Add helper elf routines (v2)
      xsplice: Implement payload loading (v2)
      xsplice: Implement support for applying/reverting/replacing patches. (v2)
      xsplice: Add support for bug frames. (v2)
      xsplice: Add support for exception tables. (v2)
      xsplice: Add support for alternatives


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel