+++ Josh Poimboeuf [16/07/15 11:22 -0500]:
The kernel module loader would automatically resolve
some_exported_vmlinux_sym and do the .rela.text relocation.
Then, when the patch module registers with klp, klp_init_object_loaded()
would be called for vmlinux. It would resolve
some_unexported_vmlinux_sym and would then call apply_relocate_add(),
passing it the symbol indices for __klp_rela_vmlinux.rela.text and
__klp_symtab_vmlinux.
The same would happen for the module with some_module_sym,
__klp_rela_modname.rela.text and __klp_symtab_modname. This would work
whether the module is already loaded, or if it were loaded later and
patched via the klp module notifier.
It's not as simple as the original proposal, but IMO it's much simpler
than having to do arch-specific dynrelas, and it allows us to keep
delayed module patching.
I probably missed some important details, but it at least seems like a
promising idea. Thoughts?
Ah, that is pretty clever! :-) I think this general approach would work on
x86. But...I think I see a few problems if we try calling
apply_relocate_add() on s390x..
Recall that on s390x, arch-specific structs carrying each symbol's plt
and got offsets are allocated for every symbol in the module's symtab.
This is done in module_frob_arch_sections() in
arch/s390/kernel/module.c
If we remove and split up the symbols into klp managed symbol tables and
rela secs, these symbols won't get plt/got offsets assigned to them,
or even get entries allocated for them, because those symbols won't be
in the module's main symbol table.
If we break these expectations, calling apply_relocate_add() from within
klp on s390 won't work unfortunately :( there's too much reliance on
those structures being there internally.
But wait, if the module loader can't allocate these entries for us, why
don't we allocate our own? There are problems with this solution too.
This solution would then be architecture-dependent, and if we want to
call apply_relocate_add(), we might have to rewrite where the module
expects its plt table to be (i.e. change module->arch.plt_offset) as
well as where it expects its syminfo table (the one containing all the
symbol plt+got offsets and stuff) to be, and that isn't good.
I hate to point out problems without offering an alternative solution,
but at the moment I'm not sure if there is a way around this if we
want livepatch to be arch-independent. So still thinking...
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
