Thread (60 messages) flat view 60 messages, 6 authors, 2015-11-16

Re: [RFC PATCH 0/5] Arch-independent livepatch

From: Josh Poimboeuf <hidden>
Date: 2015-11-11 16:28:13
Also in: lkml

On Wed, Nov 11, 2015 at 03:00:44PM +0100, Miroslav Benes wrote:
quoted
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.
I haven't yet reviewed the code in-depth, but overall I think this patch
set is a good idea.  It simplifies livepatch itself as well as the patch
creation process (for both kGraft and kpatch-build), so it's a win-win.

-- 
Josh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help