Changed '<filename>.o: changed function: <function>' to
'<path>/<filename>.o: changed function: <function>'
This enhances log clarity by providing the full path to the object file.
Signed-off-by: George Guo <guodongtai@kylinos.cn>
Typically, symbols within the same object file can be referenced
directly for better performance. However, when the patched code stores a
function pointer (R_390_GOTENT and rela symbol type is STT_FUNC), using
a dynrela is a safer approach. This ensures that if the function is used
as a asynchronous callback, the kernel does not attempt to execute an
invalid pointer after the module is unloaded. Instead, with a dynrela,
the kernel will invoke the original function, preventing potential
crashes.
Test program: Test if the original function ptr address is printed
during patch load / unload.
0f400db024
Patched code (function ptr rela):
void *patchme(void) { printk(KERN_NOTICE "patched\n"); return patchme; }
0: c0 04 00 00 00 00 jgnop 0 <patchme>
6: eb ef f0 88 00 24 stmg %r14,%r15,136(%r15)
c: c4 28 00 00 00 00 lgrl %r2,c <patchme+0xc>
e: R_390_GOTENT .LC0+0x2
12: b9 04 00 ef lgr %r14,%r15
16: e3 f0 ff e8 ff 71 lay %r15,-24(%r15)
1c: e3 e0 f0 98 00 24 stg %r14,152(%r15)
22: c0 e5 00 00 00 00 brasl %r14,22 <patchme+0x22>
24: R_390_PLT32DBL _printk+0x2
28: c4 28 00 00 00 00 lgrl %r2,28 <patchme+0x28>
2a: R_390_GOTENT patchme+0x2 <- func ptr
2e: eb ef f0 a0 00 04 lmg %r14,%r15,160(%r15)
34: c0 f4 00 00 00 00 jg 34 <patchme+0x34>
36: R_390_PC32DBL __s390_indirect_jump_r14+0x2
3a: 07 07 nopr %r7
3c: 07 07 nopr %r7
3e: 07 07 nopr %r7
Reference:
1. https://github.com/dynup/kpatch/issues/1437
2. https://github.com/dynup/kpatch/pull/755
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
When building a livepatch, we assume symbols from "readelf -s" is the
same as the order observed in kallsyms. We calculate sympos of a symbol
based on this order (readelf -s). However, with gcc-14, "readelf -s"
may present the symbols in a different order. For example:
With gcc 13:
32951: ffff8000802edf20 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
33497: ffff8000802fb798 236 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
47034: ffff80008044b250 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
51466: ffff8000804be260 236 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
51483: ffff8000804bf6a8 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
52287: ffff8000804cb098 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
54066: ffff800080518e38 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
58217: ffff800080575bb0 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
72912: ffff8000806c5dc0 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
73719: ffff8000806eccd0 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
With gcc 14:
9557: ffff800080312f28 236 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
16599: ffff8000806eb060 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
17305: ffff800080711d30 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
63960: ffff800080305540 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
74577: ffff800080466030 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
78568: ffff8000804dc3e0 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
79372: ffff8000804e81c0 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
81016: ffff800080537380 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
84685: ffff800080595428 172 FUNC LOCAL DEFAULT 2 zero_user_segments.constprop.0
Fix this by calculating sympos in another for_each_obj_symbol loop.
Signed-off-by: Song Liu <song@kernel.org>
In commit [1], kpatch added support for function padding,
and CONFIG_CFI_CLANG, which hardcoded a value of 16 for
the prefix size.
In some cases, the padding around __cfi prefixed functions can
vary. For example, in Photon OS 5.0, the __cfi prefix
size is modified in a patch for the gcc RAP plugin [2].
Since we have read the prefix size anyways, we can use it
instead of hardcoding.
Ref:
1. 3e54c63b17
2. https://github.com/vmware/photon/blob/5.0/SPECS/linux/secure/gcc-rap-plugin-with-kcfi.patch
Signed-off-by: Brennan Lamoreaux <brennan.lamoreaux@broadcom.com>
The __mcount_loc section contains the addresses of patchable ftrace
sites which is used by the ftrace infrastructure in the kernel to create
a list of tracable functions and to know where to patch to enable
tracing of them. On some kernel configurations, section is called
__patchable_function_entries and is generated by the compiler. Either of
__mcount_loc or __patchable_function_entries is recognised by the kernel
but for these configurations, use __patchable_function_entries as it is
what is expected.
The x86_64 arch is special (of course). Unlike other arches (ppc64le
and aarch64) a x86_64 kernel built with -fpatchable-function-entry will
generate nops AND create rela__patchable_function_entries for functions even
marked as notrace. For this arch, always create __mount_loc sections and
rely on __fentry__ relocations to indicate ftrace call sites.
Note: this patch is a refactoring of original code by Pete Swain
<swine@google.com> for aarch64. At the same time, this version squashes
several follow up commits from him and zimao <zimao@microsoft.com>. The
intent is minimize the eventual changeset for aarch64 support now that
other arches are making use of __patchable_function_entries sections.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Add -std=gnu11 to CFLAGS for kpatch-build tooling. This aligns with the
kernel build and avoids confusion when older tooling may default to
earlier versions.
Closes: #1416 ("C99 code vs. gcc defaults?")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Fix the following:
In kpatch/kpatch line 358:
break
^-- SC2317 (info): Command appears to be unreachable. Check usage (or ignore if invoked indirectly).
In kpatch-build/kpatch-build line 1424:
"$TOOLSDIR"/create-diff-object $CDO_FLAGS "orig/$i" "patched/$i" "$KOBJFILE_NAME" \
^--------^ SC2086 (info): Double quote to prevent globbing and word splitting.
In kpatch-build/kpatch-build line 1494:
MAKEVARS[$idx]=${MAKEVARS[$idx]/${KPATCH_CC_PREFIX}/}
^--^ SC2004 (style): $/${} is unnecessary on arithmetic variables.
In kpatch-build/kpatch-build line 1510:
"$TOOLSDIR"/create-klp-module $extra_flags "$TEMPDIR/patch/tmp.ko" "$TEMPDIR/patch/$MODNAME.ko" 2>&1 | logger 1
^----------^ SC2086 (info): Double quote to prevent globbing and word splitting.
In test/integration/lib.sh line 119:
tdnf install -y linux-$flavor-debuginfo
^-----^ SC2086 (info): Double quote to prevent globbing and word splitting.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
squash
On NixOS files are installed with mode 444 (read-only). This causes
directories in $TEMPDIR to be read-only as well, because they are
created by:
cp -LR "$DATADIR/patch" "$TEMPDIR" || die
which preserves the mode of the directory. We could do
--no-preserve=mode, but this will make people with non-coreutils cp
unhappy. Instead just chmod the files after copying.
If this patch is not applied, cleanup complains like this:
rm: cannot remove '/home/julian/.kpatch/tmp/patch/kpatch.h': Permission denied
rm: cannot remove '/home/julian/.kpatch/tmp/patch/Makefile': Permission denied
rm: cannot remove '/home/julian/.kpatch/tmp/patch/kpatch-macros.h': Permission denied
...
Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
-mno-pic-data-is-text-relative compiler flag expects -fPIC/-fPIE flag
along with it. Since kernel commit 778666df60f0 ("s390: compile
relocatable kernel without -fPIE"), the -fPIC/-fPIE flag is missing when
creating kpatch module and this can lead to the following error:
cc1: error: ‘-mno-pic-data-is-text-relative’ cannot be used without
‘-fpic’/‘-fPIC’.
Previously kpatch-build didnt show up this issue, as the previous kernel
was built with -fPIE.
However, kpatch build could fail with kernel commit 778666df60f0 ("s390:
compile relocatable kernel without -fPIE"), where -fPIE is not included.
Hence, include it in kpatch-build for all kernels < 6.10.0
Note:
Latest s390 kernel is built with -fPIC flag.
i.e. kernel commit 00cda11d3b2e ("s390: Compile kernel with -fPIC and
link with -no-pie"). Hence, there is no need to explicitly add it again
in kpatch-build.
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
When invoking kpatch-build through integration testing, like:
$ make PATCH_DIR="linux-6.9.0" \
KPATCH_BUILD_OPTS="--sourcedir /root/linux" \
integration-slow
results in an error as kpatch-build's `make kernelversion` adds
directory information to its output:
make[2]: Entering directory '/root/linux'
6.9.0
make[2]: Leaving directory '/root/linux'
This screws up kpatch-build's assignment of the make output to
LOCALVERSION, which was expecting only "6.9.0".
Add --no-print-directory to the make invocation to avoid the undesired
entering / leaving directory info.
Fixes: 629b5acf3d ("kpatch-build: Fix setlocalversion issue with 6.3 kernel")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Commit 629b5acf3d ("kpatch-build: Fix setlocalversion issue with 6.3
kernel") fixed VERMAGIC_STRING between kpatch original/patched kernel
builds by creating a temporary scripts/setlocalversion script. This was
accomplished by saving the output from `make kernelversion` into a
KERNELVERSION environment variable and running the (original)
scripts/setlocalversion to gather a "vX.Y" + "<src version>" pair of
strings.
Unfortunately pre-v6.3 scripts/setlocalversion does not use the
KERNELVERSION environment variable, so the same efforts results in an
unusable "<NULL>" + "<src version>" version string pair.
Restore the original `scripts/setlocalversion --save-scmversion`
invocation for source trees that (still) support the --save-scmversion
option.
Fixes: 629b5acf3d ("kpatch-build: Fix setlocalversion issue with 6.3 kernel")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Commit 69e71f8dcc ("kpatch-build: cleanup kernel file backup/restore")
consolidated a bunch of kernel-tree copy and restoring. As part of that
effort, when kpatch-build is invoked with a -s|--sourcedir USERSRCDIR
value the vmlinux file is now saved to "$TEMPDIR/kernel-backup/" and not
simply "$TEMPDIR/". This results in kpatch-build confusion like:
readelf: /home/jolawren/.kpatch/tmp/vmlinux: Error: No such file
Update the VMLINUX reassignment in this case to point to the new path.
Fixes: 69e71f8dcc ("kpatch-build: cleanup kernel file backup/restore")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
When kpatch-build is invoked with a -s|--sourcedir USERSRCDIR value,
kpatch-build doesn't source the /etc/os-release file as it can't assume
that the user-specified kernel source config matches any particular
distribution. Subsequent is_supported_{rpm,deb}_distro() function calls
will result in ugly syntax errors like:
kpatch-build: line 697: SUPPORTED_RPM_DISTROS: bad array subscript
kpatch-build: line 692: SUPPORTED_DEB_DISTROS: bad array subscript
Enhance the is_supported_{rpm,deb}_distro() functions to check that a
non-NULL distribution string argument exists before indexing the
SUPPORTED_{RPM,DEB}_DISTROS associative arrays.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Make kpatch-build aware about the ID of Amazon Linux distributions. No
other special changes are needed.
Signed-off-by: Puranjay Mohan <pjy@amazon.com>
Temporarily editing kernel tree sources has become a recurring
requirement in kpatch-build. Pull the saving/restoring of these files
into a common function helpers to standardize the pattern.
Reported-and-tested-by: Zhijun Wang <zhijwang@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Upstream kernel v6.1+ commit linux@e1789d7c752e ("kbuild: upgrade the
orphan section warning to an error if CONFIG_WERROR is set") and
CONFIG_WERROR will result in failed kernel builds due to the linker
reporting tons of "unplaced orphan section `.text.<function>`
<object-file.o>" errors.
Workaround this by temporarily demoting such errors in the top-level
kernel Makefile.
Reported-and-tested-by: Zhijun Wang <zhijwang@redhat.com>
Closes: #1391 ("CONFIG_WERROR=y and CONFIG_LD_ORPHAN_WARN_LEVEL="error" break kpatch-build")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Upstream kernel commit f7af6977621a ("x86/paravirt: Remove no longer
needed paravirt patching code") v6.8+ removed the .parainstructions
section and its paravirt_patch_site struct. Therefore this checks the
kernel version and does not export the struct size if the kernel
version is >= v6.8.0, avoiding the code path for it in
create-diff-object.c entirely.
Fixes: https://github.com/dynup/kpatch/issues/1380
Signed-off-by: Ryan Sullivan <rysulliv@redhat.com>
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>
