+++ Jessica Yu [16/07/15 19:14 -0400]:
+++ 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...
Hm, we might be able to avoid this whole PLT/GOT debacle if we
(through kpatch-build) swapped out PLT/GOT reloc types for
R_390_PC32DBL. If this is possible, then I think your solution would
work.
Doing a quick analysis of reloc types and their usage
in the s390 kernel showed that only modules used PLT relocs (makes
sense, only modules would have PLT/GOT tables allocated) for
invocations of global/nonstatic functions, and if those same funcs were called
somewhere in vmlinux, R_390_PC32DBL relocs were used instead. For
example, an invocation of printk from a kernel module would have a
R_390_PLT32DBL reloc, and an invocation of printk from vmlinux would
have a R_390_PC32DBL reloc. If this really works, then we could still
reuse module loader code and we'd avoid dealing with the whole plt
entry allocation craziness. I don't know if this approach is just
asking for trouble though. Will test with a few test modules to see.
--
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
