Re: [RFC PATCH 0/5] Arch-independent livepatch
From: Miroslav Benes
Date: Wed Nov 11 2015 - 09:00:49 EST
On Mon, 9 Nov 2015, Jessica Yu wrote:
> This patchset removes livepatch's need for architecture-specific relocation
> code by leveraging existing code in the module loader to perform
> arch-dependent work. Specifically, instead of duplicating code and
> re-implementing what the apply_relocate_add() function in the module loader
> already does in livepatch's klp_write_module_reloc(), we reuse
> apply_relocate_add() to write relocations. The hope is that this will make
> livepatch more easily portable to other architectures and greatly reduce
> the amount of arch-specific code required to port livepatch to a particular
thanks for the patch set. I started going through it but it is gonna take
some time. Nevertheless I've already found few things which I need to
clarify. See respective patches.
> Background: Why does livepatch need to write its own relocations?
> A typical livepatch module contains patched versions of functions that can
> reference non-exported global symbols and non-included local symbols.
> Relocations referencing these types of symbols cannot be left in as-is
> since the kernel module loader cannot resolve them and will therefore
> reject the livepatch module. Furthermore, we cannot apply relocations that
> affect modules not loaded yet at run time (e.g. a patch to a driver). The
> current kpatch build system therefore solves this problem by embedding
> special "dynrela" (dynamic reloc) sections in the resulting patch module
> elf output. Using these dynrela sections, livepatch can correctly resolve
> symbols while taking into account its scope and what module the symbol
> belongs to, and then manually apply the dynamic relocations.
I'll only add that we solve the problem with kallsyms calls in kGraft. It
can get really cumbersome from time to time, so this work would simplify
our effort as well.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/