OpenCloudOS is a centos-like Linux distribution.
I test kpatch in OpenCloudOS V8 and V9.
It works well in V9. But v8 itself has two problems:
1. no available epol repo, so kpatch can't install ccache.
2. executing 'uname -r' can't get an accurate kernel version.
Both problems have been notified to the OpenCloudOS community.
After they fix these problems, kpatch will work well in all versions.
Signed-off-by: Longjun Luo <luolongjuna@gmail.com>
Rather than adding yet another set of conditionals to handle the Anolis
OS distribution, refactor the SUPPORTED_DISTROS code using an
associative array. The array is keyed by the short distro name, and
contains the longer distribution description.
Signed-off-by: Wardenjohn<zhangwarden@gmail.com>
kpatch-build uses gawk to find special section, but gawk is not
always installed. So check if gawk is installed.
Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn>
Verify_patch_files() use `lsdiff` to get patches' path and verify
they are supported. To be consistent with apply_patches() which
using `patch -p1`, `lsdiff` should use '--strip=1' paremeter.
Close: #1357
Signed-off-by: Kai Zhang <zhangkai@iscas.ac.cn>
VMware's Photon OS uses kpatch to build kernel livepatches, starting with 3.0.
Add some changes to support Photon OS in kpatch, so we can use kpatch-build
in Photon like:
kpatch-build <name>.patch.
This commit integrates Photon OS support into existing kpatch-build support code
for various distros.
If the file doesn't have local object/func symbols, any empty match will
do, and duplicate matching local symbol lists aren't a problem.
Fixes#1345.
Reported-by: lzwycc <lzw32321226@163.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Backport this kernel commit to kpatch's version of gcc-common.h:
commit e6a71160cc145e18ab45195abf89884112e02dfb
Author: Kees Cook <keescook@chromium.org>
Date: Wed Jan 18 12:21:35 2023 -0800
gcc-plugins: Reorganize gimple includes for GCC 13
The gimple-iterator.h header must be included before gimple-fold.h
starting with GCC 13. Reorganize gimple headers to work for all GCC
versions.
Reported-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Link: https://lore.kernel.org/all/20230113173033.4380-1-palmer@rivosinc.com/
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Note that we can't directly copy the gcc-plugin headers from the kernel
as has it has dropped gcc-4.9 and older support since v5.16. Distros
like rhel-7 still use gcc-4.8, so manually cherry pick changes into the
kpatch tree.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Kernel v6.2+ commit bea75b33895f ("x86/Kconfig: Introduce function
padding") added 16 bytes of NOP padding in front of each function.
For objects built with --function-sections, this means that function
symbols no longer sit at the beginning of their respective ELF sections,
but 16 bytes offset.
In the same release, kernel v6.2+ commit 9f2899fe36a6 ("objtool: Add
option to generate prefix symbols") adds ELF function symbols with
prefix "__pfx_" to indicate the start of a function, inclusive of
NOP-padding.
For example:
$ objdump -Dr -j.text.cmdline_proc_show fs/proc/cmdline.o
...
Disassembly of section .text.cmdline_proc_show:
0000000000000000 <__pfx_cmdline_proc_show>:
0: 90 nop
1: 90 nop
2: 90 nop
3: 90 nop
4: 90 nop
5: 90 nop
6: 90 nop
7: 90 nop
8: 90 nop
9: 90 nop
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
0000000000000010 <cmdline_proc_show>:
10: e8 00 00 00 00 callq 15 <cmdline_proc_show+0x5>
11: R_X86_64_PLT32 __fentry__-0x4
15: 55 push %rbp
16: 48 8b 35 00 00 00 00 mov 0x0(%rip),%rsi # 1d <cmdline_proc_show+0xd>
19: R_X86_64_PC32 saved_command_line-0x4
1d: 48 89 fd mov %rdi,%rbp
20: e8 00 00 00 00 callq 25 <cmdline_proc_show+0x15>
21: R_X86_64_PLT32 seq_puts-0x4
25: 48 89 ef mov %rbp,%rdi
28: be 0a 00 00 00 mov $0xa,%esi
2d: e8 00 00 00 00 callq 32 <cmdline_proc_show+0x22>
2e: R_X86_64_PLT32 seq_putc-0x4
32: 31 c0 xor %eax,%eax
34: 5d pop %rbp
35: e9 00 00 00 00 jmpq 3a <cmdline_proc_show+0x2a>
36: R_X86_64_PLT32 __x86_return_thunk-0x4
Kpatch-build needs to gracefully handle NOP-padding when it is present.
At the same time, it should include "__pfx_<function>" symbols when
their respective functions change, but not treat prefix such functions
as first-class functions.
This also adds support for CONFIG_CFI_CLANG, which also creates prefixed
symbols with the name "__cfi_<function>".
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Kernel v6.2+ commit de3d098dd1fc ("powerpc/64: Add module check for ELF
ABI version") now verifies the ELF header e_flags for its ABI value and
refuse to load modules with complaint, "Invalid module architecture in
ELF header: 21"
Like other ELF header details, copy the flags from the reference ELF
input file to the new ELF file to avoid module load errors.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Kernel v6.2+ commit bea75b33895f ("x86/Kconfig: Introduce function
padding") introduces the -fpatchable-function-entry=16,16 build flag on
x86. This leverages compiler support for generating a
__patchable_function_entries section similar to __mcount_loc.
That said, x86 still utilizes __mcount_loc even when
__patchable_function_entries exists. The latter point to the __pfx
symbols, but the section is discarded in the vmlinux link and isn't used
regardless, for ftrace or for any other purpose.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
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>
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>
Kernel v6.2+ commits 00abd3840812 ("objtool: Add .call_sites section")
and e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking") added .call_sites sections to object files. These are filled
with an array of s32 values.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Kernel v6.1+ commit 2df8220cc511 ("kbuild: build init/built-in.a just
once") split init_uts_ns and linux_banner out to
init/version-timestamp.c from init/version.c
Add init/version-timestamp.o to the list of object files that kpatch-cc
won't add to its changed_objs list.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Architectures like ppc64le may set CONFIG_PARAVIRT=y but do not
necessarily implement via struct paravirt_patch_site.
Signed-off-by: Joe Lawrence <joe.lawrence@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>
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>
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]
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>
For consistency with what the kernel does (and what we already do for
in-tree modules), if the file has any dashes ('-'), replace them with
underscores in the objname (aka KBUILD_MODNAME).
Fixes#1286.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
To support building out-of-tree kernel modules, the source tree prefix
is attempted to be stripped from change object file paths to make them
relative. However, if the path is already relative, the change can
strip a substring instead, resulting in build errors.
Ensure just the prefix is stripped instead of any substring.
Fixes: #1282
Fixes: 51a8fad34f ("Add support for building out-of-tree modules")
Recent toolchains only create a section symbol if it's needed, i.e. if
there's a reference to it. If there's a missing section symbol in
kpatch_create_intermediate_sections(), create one instead of erroring
out.
Fixes#1272.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>