If an activeness safety check fails for kernels newer than 4.6, the
error is silently ignored because the newer version of
kpatch_backtrace_address_verify() doesn't set args.ret on error.
It would be an easy fix to just set args->ret on error, but I think a
better approach is just to combine the two versions of the function into
a single function with the use of a little macro trickery.
Backport the symbol lookup and checking code from upstream livepatch
code that relies on a symbol position enumeration rather than a fixed
memory address.
Fixes#617.
ftrace only allows a single user of this flag to register for a given
function. This prevents kpatch conflicts with kprobes handlers which
also might want to change regs->ip for a function.
We should have done this a few years ago. Better late than never...
When building against a different kernel from the one that is currently
running, install the kernel module to a directory based on the version
of the target kernel rather than the currently running kernel.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Upstream commit 568b329a "perf: generalize perf_callchain" modified the
return type (void -> int) of the address member of struct stacktrace_ops.
Use the void function if the kernel version is < 4.6 or return an int
otherwise.
When a patch module is loaded, the kernel facilities like alternatives
and paravirt may alter some of its instructions. This happens before
Kpatch core module is notified and tries to apply dynrelas to it. If an
instruction to apply a dynrela to has already been changed by these
facilities, an incorrect instruction might be written as a result.
The core module now detects such conditions and does not apply dynrela
to the changed instructions.
Suggested by Josh Poimboeuf in the discussion of
https://github.com/dynup/kpatch/issues/580.
Changes in v.2:
* Used pr_notice to give more emphasis to the messages.
* Added an explanation message.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Commit 7523e4dc5057 upstream ("module: use a structure to encapsulate
layout") uses a new field to access module memory. Account for this change
and ensure backwards compatibility with kernel versions < 4.5
Support patching objects that have duplicated function names. This feature was
introduced upstream in Linux v4.5.
This patch appends the symbol position to the symbol structure when
lookup_local_symbol is called. This pos variable is then used when creating the
funcs and dynrelas sections. Finally, incorporate sympos into the livepatch
patch hook only if the kernel version is greater than v4.5. In other cases the
older format is used.
Fixes: #493
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
In some cases when packaging it may not be useful to build kmod/core at
package build time (for example if using DKMS). Add a parameter 'BUILDMOD'
that when set to 'yes' will build kmod/core.
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Don't assume we are building for the current kernel. In addition print out
a proper package necessary for building the module.
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Fixes issue #494. A null pointer dereference can result with patch
modules for multiple objects since the "vmlinux" patch object's "name"
field is null. strcmp therefore crashes trying to compare object->name
if the current object is vmlinux and the supplied "name" argument is
not. Check that object->name is not null before invoking strcmp.
The shadow_get function does't consider the case that
'shadow is inpace', and after the shadow->data be set to the data,
it will not be the pointer. This patch fix it.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
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.
