The kernel has a VERMAGIC_STRING, e.g. "6.2.0". The module loader uses
that string to ensure that all loaded modules' version strings match the
kernel's.
If the kernel source is in a git tree, and if there are uncommitted
changes, the version string will have a '+' or "-dirty" appended to it,
like "6.1.0+" or "6.2.0-dirty". This dirty tree detection is done by
the setlocalversion script.
This affects kpatch-build in a few ways. When it builds the original
kernel, in some cases there are uncommitted changes to the makefiles.
When it builds the patched kernel, there are additional uncommitted
changes due to the .patch file being applied.
We want to avoid the VERMAGIC_STRING changing between builds. Otherwise
it would cause problems:
- object code which uses that string would change unnecessarily,
causing a false positive change detected by create-diff-object
- the linked patch module would report the wrong version, resulting in
the module failing to load due to version mismatch.
Up until now, the version was prevented from changing by running
`setlocalversion --save-scmversion` before the build. That command
hard-codes the version by saving it to a file which is then
automatically read later during future invocations of the kernel build.
Unfortunately that feature was removed in the 6.3 merge window with
commit f6e09b07cc12 ("kbuild: do not put .scmversion into the source
tarball"). So we need to come up with a new approach.
Fix it by temporarily replacing the setlocalversion script with a
one-liner which just echo's the original version. I think this is
unfortunately the best we can do, as we really can't handle
VERMAGIC_STRING changing, either during/between kernel builds or during
the module link.
Fixes#1335.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Updates of interest:
v0.9.8:
- Clang fix ups from Pete Swain
- Support for gcc-12
- Support for Linux 5.19
- Added RHEL-8.7 and 9.1 integration tests
- Fixed __UNIQUE_ID() variable correlation
- Improved handling of unsupported static calls
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Like unsupported jump labels and static call sites, batch report all
unsupported sibling calls so the kpatch developer doesn't need to
iteratively find them all.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
This is a test example currently preferable to proc-version.patch as
crash utility has difficulty parsing /proc/version content after being
altered.
Signed-off-by: Linqing Lu <lilu@redhat.com>
The term "dynrela" was invented before klp relocations ever existed.
They're basically the same thing: special livepatch-specific relocations
which get applied when the patched object gets loaded or patched.
They're necessary due to a) the need to access unexported symbols; and
b) late module patching.
The different names are confusing. Consolidate them by replacing
"dynrela" with "klp_reloc" (code) or "klp relocation" (English).
Note there's still some antiquated code in the kpatch core module and in
the pre-4.7 klp patch template which still use the "dynrela" naming.
That code is mostly dead anyway so I've just left it alone.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Now that we have KPATCH_STATIC_CALL(), document its usage. While at it,
give a more thorough description for why jump labels and static calls
aren't supported in some scenarios.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
For some reason the github version of 'make check' just started
complaining about these:
shellcheck kpatch/kpatch kpatch-build/kpatch-build kpatch-build/kpatch-cc
In kpatch-build/kpatch-build line 455:
while [[ "${filedir#$common/}" = "$filedir" ]]; do
^-----^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
while [[ "${filedir#"$common"/}" = "$filedir" ]]; do
In kpatch-build/kpatch-build line 460:
result="${result}${filedir#$common/}"
^-----^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
result="${result}${filedir#"$common"/}"
In kpatch-build/kpatch-cc line 26:
relobj=${obj##$KPATCH_GCC_SRCDIR/}
^----------------^ SC2295 (info): Expansions inside ${..} need to be quoted separately, otherwise they match as patterns.
Did you mean:
relobj=${obj##"$KPATCH_GCC_SRCDIR"/}
For more information:
https://www.shellcheck.net/wiki/SC2295 -- Expansions inside ${..} need to b...
make: *** [Makefile:70: check] Error 1
Error: Process completed with exit code 2.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Otherwise on recent distros it appends the errno to the error message,
like:
create-diff-object: ERROR: x86.o: kpatch_regenerate_special_section: 2633: Found 1 unsupported static call(s) in the patched code. Use KPATCH_STATIC_CALL() instead.: Success
which is not what we want in most cases.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Similar to jump labels, static calls aren't supported when the static
call key was originally defined in a module rather than in vmlinux.
Detect those cases and either remove them (in the case of tracepoints)
or error out.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Convert the hard-coded should_keep_jump_label() to a proper callback,
since static calls will need a similar filter.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Align the s390 special_section initializers to improve readability and
for consistency with the rest.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
kpatch_mangled_strcmp() only ignores the digits after the period, but in
the case of __UNIQUE_ID(), the symbol names have random digits before
the period due to the use of `__COUNTER__`. Make sure such symbols are
properly correlated.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Create a simple kpatch test that should apply across a wide range of
kernels. The version_proc_show() is a good candidate as it's easy to
verify and hasn't been touched upstream since 2008.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Rewrite kobj_find() to deal with Linux 5.19, where the .cmd files use
object file paths relative to the .cmd file rather than relative to the
root of the kernel tree.
While at it, add several performance enhancements to prevent all
currently known deep finds.
This is all quite fiddly. But it works.
Fixes#1277.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
When patching an OOT module, the parent object is always the OOT module.
Hard-code that to prevent the need for any further special casing in
find_kobj() (e.g., commit 9143e88f16 ("kpatch-build: fix
find_parent_obj")).
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Fix build error seen on gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1):
g++ -MMD -MP -I../kmod/patch -Iinsn -Wall -Wsign-compare -Wno-sign-conversion -g -Werror -shared -I/usr/lib/gcc/ppc64le-redhat-linux/12/plugin/include -Igcc-plugins -fPIC -fno-rtti -O2 -Wall gcc-plugins/ppc64le-plugin.c -o gcc-plugins/ppc64le-plugin.so
In file included from /usr/include/features.h:490,
from /usr/include/bits/libc-header-start.h:33,
from /usr/include/stdio.h:27,
from /usr/lib/gcc/ppc64le-redhat-linux/12/plugin/include/system.h:46,
from /usr/lib/gcc/ppc64le-redhat-linux/12/plugin/include/gcc-plugin.h:28,
from gcc-plugins/gcc-common.h:6,
from gcc-plugins/ppc64le-plugin.c:1:
/usr/include/bits/error-ldbl.h:23:1: error: type of ‘error’ is unknown
23 | __LDBL_REDIR_DECL (error)
| ^~~~~~~~~~~~~~~~~
/usr/include/bits/error-ldbl.h:23:1: error: ‘int error’ redeclared as different kind of entity
23 | __LDBL_REDIR_DECL (error)
| ^~~~~~~~~~~~~~~~~
In file included from gcc-plugins/ppc64le-plugin.c:2:
/usr/include/error.h:31:13: note: previous declaration ‘void error(int, int, const char*, ...)’
31 | extern void error (int __status, int __errnum, const char *__format, ...)
| ^~~~~
make[1]: *** [Makefile:39: gcc-plugins/ppc64le-plugin.so] Error 1
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Clang FDO adds a new, ignorable ELF section, .llvm.call-graph-profile
Generalize to ignore all .llvm.*
Signed-off-by: Pete Swain <swine@google.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> [subject line]
While gcc puts strings in .strtab and .shstrtab sections,
llvm toolchain just uses .strtab.
Adapt kpatch to handle both styles.
Signed-off-by: Pete Swain <swine@google.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> [small changes]
Update the unit test submodule reference to include ppc64le files w/o
.eh_frame. At the same time, give additional guidance on stripping
these sections going forward.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
If two sections want to be the same, they need to satisfy
two conditions:
1) the result of memcmp is zero, which means they
have the same content.
2) they have the same relocation entries.
In one specific situation, two sections have the same content.
But one section has relocation entries while the other one has
no relocation entries. For example, in X86, consider the
following code:
original code
```
__noreturn noinline int kpatch_func(void)
{
while(1) {};
}
```
patched code
```
__noreturn notrace noinline int kpatch_func(void)
{
asm(".byte 0xe8, 0x00, 0x00, 0x00, 0x00");
while(1){};
}
```
Since the original code has a fentry call, these two functions have
the same compile result. But obviously, they are different functions.
Currently, kpatch would not find their differences since the patched
code has no relocation entries.
For the situation that one section has relocation entries while the
other one doesn't have, it should be set to be changed directly.
Cooperated-by: Zongwu Li <lizongwu@huawei.com>
Signed-off-by: Longjun Luo <luolongjuna@gmail.com>
After patched, rela information for some sections could
disappear. For example, a function like the following:
"
notrace noinline static int version_proc_show(struct seq_file *m,
void *v)
{
return 0;
}
"
Apart from common rela entries, trace and return thunk mechanism
will generate rela information. Use `notrace` to remove the
effect of trace. Make CONFIG_RETHUNK=n can remove the effect of
return thunk.
Discovered-by: Zongwu Li <lizongwu@huawei.com>
Signed-off-by: Longjun Luo <luolongjuna@gmail.com>
