[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH v2] xSplice v1 implementation.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |