This commit adds support for module patching with kpatch-build.
It introduces a new option, -t/--targets, that allows the user to
specify kernel make targets that are impacted by the patch. These
targets will be examined by kpatch-build for changes.
While this approach requires the user to provide more information to
kpatch-build about what exactly has changed, it is better that
rebuilding the entire source tree (make vmlinux && make modules) which
would dramatically increase the runtime and disk space requirements of
using kpatch-build.
Future improvements could include a script that will independently
generate the targets list file.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
With test/integration/data-read-mostly.patch, create-diff-object
includes the __verbose section but not the .rela__verbose section, which
is a bug, resulting in the following printk during the integration
tests:
[13740.801920] dynamic debug error adding module: (null)
If a non-bundled section is included, its rela section should also be
included. Also add support for converting those relas to dynrelas.
When renaming a foo.isra.1 function, there might also be a foo_bar
function which would be falsely matched with the current strchr logic.
Instead of matching the "foo" prefix, match "foo.isra".
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.
