Adds a new patch module scaffold for use when building against a kernel
with CONFIG_LIVE_PATCHING=y.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Unload of kpatch module (and kpatch_shadow_hash table) before
all shadow variables free requests are processed can lead to
kernel crash.
Add rcu_barrier() to kpatch_exit() to wait for all outstanding
RCU callbacks to complete.
Signed-off-by: Jan Stancek <jstancek@redhat.com>
When patching a kernel module, if we can't find a needed dynrela symbol,
we currently assume it's exported. However, it's also possible that
it's provided by another .o in the patch module. Add support for that.
Fixes#445.
Fix the object unlink error handling so that each function cleans up
after itself properly.
Also use find_symbol() instead of __symbol_get() to make cleanup easier.
When patching a module we don't need a reference to each symbol, since
we already have done a try_module_get() on the module.
Fixes#392.
Make the kpatch-patch-hook.c function and variable names consistent by
prefixing them all with 'patch_'. This makes it easier to distinguish
the patch hook sections from the patched sections when looking at the
ELF section data.
In order to safely re-enable patch modules, add a special
.kpatch.checksum section containing an md5sum of a patch module's
contents. The contents of this section are exported to sysfs via
patch_init and double checked when kpatch load finds that a module of
the same name is already loaded.
This adds support for shadow variables, which allow you to add new
"shadow" fields to existing data structures.
To allow patches to call the shadow functions in the core module, I had
to add a funky hack to use --warn-unresolved-symbols when linking, which
allows the patched vmlinux to link with the missing symbols. I also
added greps to the log file to ensure that only unresolved symbols to
kpatch_shadow_* are allowed. We can remove this hack once the core
module gets moved into the kernel tree.
Fixes#314.
To reduce redundancy, remove/change the old_offset fields in the
kpatch_func and kpatch_patch_func structs to just old_addr. Since
old_offset is being used as a placeholder for old_addr, might as well
consolidate it to just one variable.
Fix incorrect old_offsets for loadable modules during sysfs
initialization in patch_init.
sysfs will be initialized on patch module init regardless of whether
or not the module is loaded. func_old_addr_show() will read from func->old_addr,
which is initially set to 0; it'll be eventually filled in by the core module.
Use this instead of calling printk to avoid unwanted compiler
optimizations which cause kpatch-build errors.
The printk function is annotated with the __cold attribute, which tells
gcc that the function is unlikely to be called. A side effect of this
is that code paths containing calls to printk might also be marked cold,
leading to other functions called in those code paths getting moved into
.text.unlikely or being uninlined.
This macro places printk in its own code path so as not to make the
surrounding code path cold.
I have a related integration test to add, but right now it's broken
because we don't yet properly support the __verbose special section.
That'll be another PR.
Fixes#296.
On RHEL I'm seeing issues with putting the core module in the "extra"
path. On the next depmod run, it gets added to modules.dep, and on a
subsequent kpatch install I see the following errors:
/usr/lib/dracut/modules.d/50drm/module-setup.sh: line 26: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
/usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh: line 14: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
modinfo: ERROR: Module /lib/modules/3.10.0-123.4.4.el7.x86_64/weak-updates/kpatch/kpatch.ko not found.
Until the core module gets merged into Linux, I think we can put it in
/usr/lib/kpatch, which is also where the patch modules are going to be
delivered in the RHEL RPM.
Making sure the other options still work with the kpatch utility for
now, so as to keep backwards compatibility between a newer kpatch
utility and older core modules. We can break this compatibility for
kpatch 0.2.0.
This macro is for ignoring sections that may change as a side effect of
another change or might be a non-bundlable section; that is one that
does not honor -ffunction-section and create a one-to-one relation from
function symbol to section.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This commit adds the KPATCH_IGNORE_FUNC() macro for ignoring functions
that may change as a side effect of a change in another function. The
WARN class of macros, for example, embed the line number in an
instruction, which will cause the function to be detected as changed
when, in fact, there has been no functional change.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
When patching a module, I ran into a "can't set ftrace filter at
address" error. The root cause was due to the fact that
mod->module_core + old_offset is apparently not a reliable way to
determine the function's address.
Instead, just get the address from kallsyms like we do for module
dynrelas.
I found a bad bug:
- Module A is loaded, and registers function foo() with
KPATCH_FORCE_UNSAFE.
- Module A is unloaded. The new version of foo() is on the backtrace of
a task, but the core module ignores it because of the force flag, so
the unloading succeeds.
- The task returns to the new version of foo() which no longer exists.
- BOOM.
The only way I can think of to prevent this scenario is to prevent
forced modules from being unloaded (but still allow them to be
disabled).
An annoying side effect of this approach is that forced modules stay
loaded and in memory forever. And that after "kpatch unload" of a
forced module, you can't ever load it again because the previous
instance of it is still loaded (but permanently disabled).
This is ugly but I can't really think of a better way to handle it. If
necessary we could create a workqueue and periodically check to see if
we can safely call module_put() so that the module could be eventually
removed.
WARN macros are problematic because they embed the line number in an
instruction. As a result, when a function is changed higher in a file,
the line numbers for any WARN calls below that function in the file can
result in unnecessarily changed functions.
These macros allow a patch author to hard code the line numbers in WARN
macros to prevent functions from otherwise changing and getting pulled
into a patch module unnecessarily.
Some functions in the kernel are always on the stack of some thread
in the system. Attempts to patch these function will currently always
fail the activeness safety check.
However, through human inspection, it can be determined that, for a
particular function, consistency is maintained even if the old and new
versions of the function run concurrently.
This commit introduces a KPATCH_FORCE_UNSAFE() macro to define patched
functions that such be exempted from the activeness safety check.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Steven Rostedt recommended to return "regs->ip + MCOUNT_INSN_SIZE",
which is what the function_graph tracer expects. This fixes
function_graph tracing for a patched function.
This change also means that the function tracer will only show the
patched function once (corresponding to a trace of the original
function) rather than twice. This is probably more in line with what a
user would expect.
Currently, when removing a patch module, the ftrace buffer gets flooded
with traces. This happens because we're clearing the ftrace ops filter
before unregistering the ops, which creates a small window where all
functions are being traced.
We should be doing the unregistering in the reverse order in which we
registered, meaning ops should be unregistered and _then_ the filter
should be cleared.
This commit enables the ability to create user-defined hooks as part of
the normal code patch that can do preparatory work for the application
of the patch. This work could include, but is not limited to, changing
data structure semantics.
The user may define a new function as part of the patch and mark it as a
load-time or unload-time hook with the kpatch_load_hook() and
kpatch_unload_hook() macros. These macros are in an include file that
gets copied into the source tree at include/linux/kpatch-hooks.h at
patch build time. The signature for both hooks is "int kpatch_unload_hook(void)".
For now, the return code is ignored. The hooks may not fail. They also
run in stop_machine() context and may not sleep. These hooks, more or
less, must follow all the rules of interrupt context code.
The integration test suite was intermittently giving the following
error:
[192685.907072] kpatch: write to 0xffffffffa082bffe failed for symbol call_netdevice_notifiers_info
The error was caused by a write across a page boundary without first
making the second page read/write.
Right now, if there is a failure in patch_make_dynrelas_list(),
patch_free_objects() is called twice; once in the error section of
patch_make_dynrelas_list() and again in the err_objects section of
patch_init().
This fixes this and cleans up the error handling a bit.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
