Updating version in preparation for rhel9 support.
Changes since v0.9.4:
- openEuler support
- kpatch-build: Do not check KLP_REPLACE for kpatch.ko-based patches
- create-diff-object: fix use after free in kpatch-check-relocations()
- kpatch-build: Handle error in create-klp-module
- create-diff-object: support ppc64le relative jump labels
- kmod/patch: clean only rebuildable objs
- kpatch-build: save environment varibles to file
Signed-off-by: Artem Savkov <asavkov@redhat.com>
The kpatch-build script sets and exports a bunch of environment varibles
like KCFLAGS as well as data structure sizes in <STRUCT>_SIZE.
Dump the current environment to $CACHEDIR/tmp/kpatch-build.env so these
values can be more easily reused later:
% source <PATH>/kpatch-build.env && <command>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Relax the clean target to leave the kpatch-build generated output.o file.
This is helpful after invoking kpatch-build in debug mode and rebuilding
$CACHEDIR/tmp/patch in a debugging session.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
RHEL-9 integration tests revealed that the kernel now makes use of
R_PPC64_REL64 relocations in the jump table, but need_dynrela() contains
code to specifically skip any R_PPC64_REL64 type when determining if a
relocation should be turned into dynrela.
Kamalesh Babulal explains:
I tried digging a little deeper and the upstream Kernel commit
b0b3b2c78ec (powerpc: Switch to relative jump labels) in v5.13,
introduced the change of generating relocation entries of type
R_PPC64_REL64, instead of absolute relocation type R_PPC64_ADDR64:
Relocation section '.rela__jump_table' at offset 0x1a87d8 contains 303 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
...
00000000000003c8 000007910000002c R_PPC64_REL64 0000000000000000 __tracepoint_netif_receive_skb + 8
...
Relax the existing check in need_dynrela() for .rela__jump_table
R_PPC64_REL64 relocations in case we need dynrelas for them.
Fixes: #1212
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
create-klp-module could error out and in this case ensure that
kpatch-build does not proceed further.
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Building data-read-mostly.patch on rhel-9.0-beta for ppc64le leads to a
segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
kpatch_check_relocations (kelf=0x10040490) at create-diff-object.c:2571
2571 sdata = rela->sym->sec->data;
(gdb) bt
(gdb) p rela->sym->sec->data
Cannot access memory at address 0x160000007e
Valgrind narrows the problem down to invalid reads through rela->sym in
kpatch-check-relocations().
The culprits are kpatch_create_intermediate_sections(), which marks
symbols referenced by rela sections that are now dynrelas to be
stripped, and kpatch_strip_unneeded_syms(), which removes and frees
them.
The problem with the symbol stripping is that multiple relas may
reference the same ELF symbol. If any remaining relocation references a
shared symbol, we must keep it.
Replace the symbol->strip boolean with an enumeration:
SYMBOL_DEFAULT - initial value, symbol usage unknown
SYMBOL_USED - symbol is definitely used by a rela
SYMBOL_STRIP - symbol was only referenced by dynrela(s)
Allow transitions from SYMBOL_DEFAULT to SYMBOL_* and SYMBOL_STRIP to
SYMBOL_USED, but _not_ SYMBOL_USED to SYMBOL_*.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
After commit 17dcebf077 ("kpatch-build: enable klp with replace option by default"),
building the old-style (kpatch.ko-based) patches fails with the following
error:
"kpatch core module (kpatch.ko) does not support replace, please add -R|--non-replace"
kpatch.ko actually supports atomic replacement of patches but KLP_REPLACE
has nothing to do with that. Let us not break such builds and remove that check.
Fixes: 17dcebf077 ("kpatch-build: enable klp with replace option by default")
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Interesting changes since v0.9.3:
- Support for multiple source files
- Makefile tweaks for handling non-replace kpatch building
- Support CONFIG_PRINTK_INDEX
- kpatch-build: set EXTRAVERSION and not localversion for RH kernels
- Make sure section symbols exist
- create-diff-object: Check that the section has a secsym
- kpatch: rmmod module of the same name before loading a module
- kpatch-build: enable option -R|--replace to build replace klp
- kpatch: use /sys/kernel/kpatch/ to check whether core module is loaded
- kpatch: Sync signal subcmd usage output with manpage
- fixes for the out-of-range relocation check
Signed-off-by: Yannick Cote <ycote@redhat.com>
While theoretically most of these functions can work both ways right now
all calls follow the same pattern: first argument is orig element and
second is patched element. Rename the arguments so that these functions
are used in the same fashion going forward. This allows us to cut some
corners such as removing the elseif statement in kpatch_correlate_symbol().
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Rename "base" to "orig" when referencing object files and their contents
to be consistent with temporary directory structure.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
So far create-diff-object worked only with objectfiles built from a
single source file. To support object-files built from multiple sources
such as linked vmlinux.o, we call locals_match() for each of STT_FILE
symbols and store the pointer to the beginning of appropriate symbol
block in lookup table in each symbol.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
At the moment lookup_symbol() takes symbol name as an argument which
might not be enough in some cases (e.g. for objectfiles built from
multiple source files). Make it accept full symbol structure.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
gcc-static-local-var-4.patch is disabled on this distribution, disable
the test as well as it will always fail during 'slow' integration test
runs.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
For each printk() call site, CONFIG_PRINTK_INDEX makes a static local
struct named `_entry`, and then adds a pointer to it in the
`.printk_index` section.
When regenerating the `.printk_index` section for the patch module, we
only need to include those entries which are referenced by included
functions. Luckily this is a common pattern already used by several
other "special" sections. Add `.printk_index` to the special section
handling logic.
Fixes: #1206
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
CONFIG_PRINTK_INDEX creates a static local struct variable named
`_entry` for every call site to printk(). The initializer for that
struct assigns the `__LINE__` macro to one of its fields.
Similarly to the WARN macro's usage [1] of `__LINE__`, it causes
problems because it results in the line number getting directly embedded
in the struct. If a line is added or removed higher up in the source
file, the `_entry` struct changes accordingly due to a change in the
printk() call site line number.
`_entry` is similar to other "special" static locals, in that we don't
need to correlate the patched version with the original version. We can
instead just ignore any changes to it.
Any substantial (non-line-number) change to the `_entry` struct would be
a second-order (dependent) effect of a first-order code change, which
would be detected using other means. In that case the patched version
of `_entry` will be included, due to being referenced by the changed
function.
Fixes: #1206
[1] See kpatch_line_macro_change_only()
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Update the test/integration/Makefile to pass a KPATCH_BUILD_OPTS
variable to kpatch-test. This allows the user better control over the
kpatch build process, for example, building non-atomic replace .ko files
on kernels that do support atomic-replace:
% make integration KPATCH_BUILD_OPTS="--non-replace"
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
In PR #1205, Kamalesh reports:
... I see that the -mcmodel=large flag is being passed twice with
KBUILD_CFLAGS_MODULE set:
gcc -Wp,-MMD,/root/.kpatch/tmp/patch/.livepatch-meminfo.mod.o.d ............ -mcmodel=medium .... -I/root/kpatch/kmod/patch -mcmodel=large -fplugin=/root/kpatch/kpatch-build/gcc-plugins/ppc64le-plugin.so ... -DMODULE -mno-save-toc-indirect -mcmodel=large -mcmodel=large -DKBUILD_BASENAME='"livepatch_meminfo.mod"' -DKBUILD_MODNAME='"livepatch_meminfo"' -D__KBUILD_MODNAME=kmod_livepatch_meminfo -c -o /root/.kpatch/tmp/patch/livepatch-meminfo.mod.o /root/.kpatch/tmp/patch/livepatch-meminfo.mod.c.
I loaded the module built without the KBUILD_CFLAGS_MODULE +=
-mcmodel=large flag and seems to okay. I guess, we can remove the arch
specific flag from the Makefile.
Suggested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
The kmod/patch/Makefile defines KBUILD_CFLAGS_MODULE, but it seems that
kbuild doesn't honor it as environment variable. This is noticed when
attempting to use the kpatch-build --non-replace option: the flag is
added to KBUILD_CFLAGS_MODULE, yet the kernel module build ignores it.
At the same time, the kernel docs suggest passing CFLAGS_MODULE [1], not
KBUILD_CFLAGS_MODULE, from the commandline. Setup KPATCH_MAKE to pass
these options through that variable.
[1] https://www.kernel.org/doc/Documentation/kbuild/makefiles.txt
Fixes: c14e6e9118 ("kpatch-build: Add PPC64le livepatch support")
Fixes: 17dcebf077 ("kpatch-build: enable klp with replace option by default")
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Binutils recently became much more aggressive about removing unused
section symbols. Since we can not rely on those being available anymore
add additional checks before using them.
Fixes: #1193
Signed-off-by: Artem Savkov <asavkov@redhat.com>
There are some Red Hat kernel NVR combinations like
"kernel-5.13.0-0.rc4.33.el9.x86_64" that don't work well with our srpm
localversion strategy and end up botching the utsrelease.h file... which
allows for kpatch builds, but the module loader rightly rejects the
vermagic mismatch.
An ordinary rpmbuild sets up the kernel Makefile with:
# make sure EXTRAVERSION says what we want it to say
# Trim the release if this is a CI build, since KERNELVERSION is limited to 64 characters
ShortRel=$(perl -e "print \"%{release}\" =~ s/\.pr\.[0-9A-Fa-f]{32}//r")
perl -p -i -e "s/^EXTRAVERSION.*/EXTRAVERSION = -${ShortRel}.%{_target_cpu}${Variant:++${Variant}}/" Makefile
The simplest fix is just adding the version string to the kernel
Makefile EXTRAVERSION as rpmbuild would do (minus the perl voodoo).
Fixes: #1196
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
With klp->replace, when a patch is replaced, it is no longer an active
patch, but the module is still loaded with a refcount of 0. If the user
tries to load the patch again, insmod will fail with EEXIT. To avoid
such errors, run a proactive rmmod before loading the module. This is a
no-op if the module is not loaded or is actually in use.
Also, update module_ref_count() to only succeed with refcnt > 1.
Signed-off-by: Song Liu <song@kernel.org>
Fixes#1187
checking if kpatch_register or klp_enable_patch exists in /proc/kallsyms
might not be reliable when module loading or unloading occurs at the same time.
The kernel implementation about /proc/kallsyms is not guranteed to be consistent.
Signed-off-by: xiejingfeng <xiejingfeng@linux.alibaba.com>
A STT_SECTION symbol is not needed if if it is not used as a relocation
target. Therefore, a section, in this case a debug section, may not have
a secsym associated with it.
Signed-off-by: Bill Wendling <morbo@google.com>
