Currently, kpatch unload passes the raw argument to basename since the
user may pass a path into the subcommand. This makes the argument hard
to validate. This can be improved since the set of acceptable inputs is
already known, namely the list of loaded patch modules.
This commit changes the kpatch unload subcommand to accept only the
module name, since kpatch should already be aware of it since it is
loaded. It is then trivial to validate the user input since, if it is
not the name of a loaded module, it is invalid.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Try to be more consistent with the naming of patch modules. They are
patch modules, where patch is the adjective and module is the noun. So
calling them patches is confusing.
In the case of "kpatch unload --all", just show the usage help instead
of this:
# kpatch unload --all
basename: unrecognized option '--all'
Try 'basename --help' for more information.
unloading patch module:
basename: unrecognized option '--all'
Try 'basename --help' for more information.
rmmod: ERROR: Module is builtin.
kpatch: failed to unload patch --all
A simple kernel module for testing basic kernel module patching.
Just run doit.sh from test/testmod.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This commit adds support for patching modules. If a patch or dynrela is
determined to be for a kernel module, the old_offset/src is not used and
the symbol location is looked up using kallsyms. The module being
patched is also references to keep if from disappearing from underneath
us.
This commit introduces early and limited support. The kernel module to
be patched must already be loaded or the patch module will not apply.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This commit adds module patching support to create-diff-object by:
1) generalizing the vmlinux CLI parameter
2) adding the kernel object name to each patch and dynrela
3) adding slightly different logic for vmlinux/module in the dynrela
creation
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Rather than keep the logic in sync between the counting and processing
code in kpatch_create_dynamic_rela_sections() just do a "dumb" count
establishing an upper bound and allocating the buffer, then determine
the actual size (i.e. number of dynrelas) in the processing section.
No functional change intended.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Make old addresses relative to the start address of the relocatable
kernel or module.
This commit has no functional effect; it just prepares the code for
future acceptance of the module patching support.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
The current approach of trying to include the tracepoint-related
sections doesn't work at all. The new tracepoints don't show up in
"perf list".
And also, with one patch (issue #219) I've seen a panic in
jump_label_del_module(). I suspect it's because the kernel is confused
by dynamic relocations' changing of the jump table after it was
registered with the jump table code.
I think the best approach for now is to just always exclude these
sections. It should be harmless, with the only consequence being that
tracepoints and jump labels can't be enabled in patched functions (which
is already the case with the current code anyway).
Fixes#221.
For a rela with type X86_64_PC32, the addend of the needed symbol is
relative to the address of the instruction _after_ the one which is the
target of the relocation.
We need a disassembler library to help with converting data section
relocation references to their corresponding symbols. Unfortunately,
the only library I could find that's widely available in enterprise
Linux distros was libopcodes, which is part of binutils. But its
interface is far too clunky for our needs.
The best alternative I can find is to just copy the kernel's
disassembler library code from arch/x86/lib.
Ensure that dynrela destination addresses are within the patch module's
memory.
Also, use the module address ranges to check whether set_memory_rw() is
needed.
When a changed function needs relocations for special data sections like
.data..percpu or .data..read_mostly, it's possible for those sections to
get included. We try to avoid that situation by converting section
references to data symbol references in kpatch_replace_sections_syms(),
but the conversion success rate isn't 100%, and we could be forgetting
about some other sections, so ensure that it never happens in
kpatch_verify_patchability().
Abstract out the common functionality for dealing with special sections
into a new kpatch_process_special_sections() function.
The base sections are partitioned into "groups". Only those groups
whose relas reference a changed function are kept. The only difference
in the logic for handling each special section is determining the size
of a given group. Each section has its own group_size() callback for
this. It's a callback instead of an integer because one of the
soon-to-be-supported special sections requires that its group sizes be
dynamically determined.
