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>
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>
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>
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>
Since 5.1 kernel, klp_patch supports a "replace" option, which does atomic
replace of cumulative patches. Enable building such patch by default. If
replace behavior is not desired, the user can use -R|--non-replace option
to disable it.
Signed-off-by: Song Liu <song@kernel.org>
Improve the relocation check for the case where the referenced symbol
isn't at the beginning of the section.
Note that the check still isn't perfect, as many relocations have a
negative addend. But it's still a lot better than nothing.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
During review of PR #1163, Josh reported:
When trying this out, I think I found that kernel_is_rhel() is broken
for z-stream kernels. It expects a "." after the el8, like ".el8.",
but [rhel-8] z-stream kernels have the minor version appended to the
major version like ".el8_3".
Tweak the regex pattern in kernel_is_rhel() to account for such z-stream
kernel versions. At the same time, add .el9 to the regex in preparation
of rhel-9.
Reported-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
create-build-diff expects .cold functions to be suffixed by an id, which
is not always the case. Drop the trailing '.' when searching for cold
functions.
Fixes: #1160
Signed-off-by: Artem Savkov <asavkov@redhat.com>
It turns out there is a stretch of time in kernel's history when
CONFIG_DEBUG_INFO_BTF was already added, but Makefile.modfinal wasn't
split off yet. To address those we need to either check the file's
existance or, as @liu-song-6 suggested initially, check config for
CONFIG_DEBUG_INFO_BTF_MODULES=y.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
With CONFIG_DEBUG_INFO_BTF_MODULES, the kernel build process adds BTF to
each in-tree modules. However, this process is broken with kpatch, with
error message like:
Failed to parse base BTF 'vmlinux': -4001
Unblock build with CONFIG_DEBUG_INFO_BTF_MODULES with similar workaround
as the one for CONFIG_DEBUG_INFO_BTF.
Signed-off-by: Song Liu <songliubraving@fb.com>
Make kpatch_mangled_strcmp treat two strings as the same in case when
one has a digit tail and the other one doesn't.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
gcc-generated static variables always have a numbered suffix, while
clang-generated static variables are always prepended with a function
name. Change is_special_static() so that it detects both cases.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
clang does not always use __UNIQUE_ID as prefix and can generate symbols
with names like this:
trace_nfsd_exp_get_by_name.__UNIQUE_ID___addressable___SCK__tp_func_nfsd_exp_get_by_name645
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Clang adds .L.str* symbols to .rodata.str sections which are used for
__FILE__ references. These are discarded during linking so add them to
maybe_discarded_sym().
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Add support for clang-built kernels. This is completely automatic, we
check if the kernel was built with clang by looking for
CONFIG_CC_IS_CLANG in config.
This has almost no effect on non-clang built kernels with one exception:
we now do compliler checks _after_ we download kernel sources which is a
waste of resources in case when compilers don't match.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Be robust and use "cp -f". Finish with "|| die" to be dead serious
about it.
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
kpatch-build requires gcc flags -f[function|data]-sections when building
original and patched targets. These flags result in an ELF binary with
many sections, potentially requiring special extended ELF header
processing to parse correctly.
CONFIG_DEBUG_INFO_BTF invokes pahole as part of the kernel build and
unfortunately pahole cannot iterate through more than 65535 section
headers. As result, the pahole program segfaults and fails the build
like so:
...
BTF .btf.vmlinux.bin.o
scripts/link-vmlinux.sh: line 127: 718345 Segmentation fault (core dumped) LLVM_OBJCOPY=${OBJCOPY} ${PAHOLE} -J ${1}
objcopy: --change-section-vma .BTF=0x0000000000000000 never used
objcopy: --change-section-lma .BTF=0x0000000000000000 never used
objcopy: error: the input file '.btf.vmlinux.bin' is empty
Failed to generate BTF for vmlinux
Try to disable CONFIG_DEBUG_INFO_BTF
make: *** [Makefile:1050: vmlinux] Error 1
Workaround this limitation by disabling CONFIG_DEBUG_INFO_BTF code in
scripts/vmlinux-link.sh during kpatch-build. This leaves
CONFIG_DEBUG_INFO_BTF contingent kernel code in place, but skips the
problematic pahole .BTF typeinfo generation step (for which kpatch
doesn't care about anyway).
Link: https://lore.kernel.org/dwarves/20210119231718.GA3173@redhat.com/T/
Link: https://lore.kernel.org/dwarves/20210121202203.9346-1-jolsa@kernel.org/T/
Link: https://lore.kernel.org/dwarves/20210122163920.59177-1-jolsa@kernel.org/T/
Link: https://lore.kernel.org/dwarves/b1469725-d462-9a6d-3329-f77c9eb6b43f@redhat.com/T/Fixes: #1153
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Starting v5.11-rc, kpatch-build fails on powerpc with the error:
ERROR: invalid ancestor arch/powerpc/kernel/vdso64/vdso64.so.dbg for arch/powerpc/kernel/vdso64/vgettimeofday.o
the upstream commit ab037dd87a2f(powerpc/vdso: Switch VDSO to generic
implementation) introduced this breakage, lets skip vdso files. They are
not compatible with kpatch.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
__verbose has renamed to __dyndbg since Linux 5.9, commit e5ebffe18e5a
("dyndbg: rename __verbose section to __dyndbg")
Signed-off-by: WANG Chao <chao.wang@ucloud.cn>
Currently all the callers of kpatch_write_output_elf() are creating
.o object files or .ko kernel modules. Neither of these filetypes are
executable on their own, so enhance kpatch_write_output_elf() to accept
file creation mode and update its callers to pass 0664 to match
the expected permissions.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
User disaster123 reports the following build errors:
create-diff-object.c: In function 'kpatch_process_special_sections':
create-diff-object.c:2215:41: error: 'key' may be used uninitialized in this function [-Werror=maybe-uninitialized]
code->sym->name, code->addend, key->sym->name);
^~
create-diff-object.c:2138:22: note: 'key' was declared here
struct rela *code, *key, *rela;
^~~
In file included from kpatch-elf.h:26,
from create-diff-object.c:53:
log.h:20:3: error: 'code' may be used uninitialized in this function [-Werror=maybe-uninitialized]
printf(format, ##__VA_ARGS__); \
^~~~~~
create-diff-object.c:2138:15: note: 'code' was declared here
struct rela *code, *key, *rela;
^~~~
cc1: all warnings being treated as errors
These are reproducible when building with 9.3.1 and 8.3.1 when building
with optimization level > 2 ( CFLAGS=-O2 make ). Fix them by
initializing the reported variables to NULL and verifying that they are
infact non-NULL after processing the __jump_table.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
If the final module has a reference in its symbol table to a kernel
symbol and the symbol version differs from the kernel symbol version,
the module will be unloadable.
Have kpatch-build emit a clear error and die in such a case instead
of providing an unusable module.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
The CRCs of exported symbols Module.symvers can differ between the
original build and the patched build.
In such a case, it is probably wise to rework the patch to avoid such
modifications.
Warn when a symbol changes version in the exported symbol list.
Fixes issue #1084
Signed-off-by: Julien Thierry <jthierry@redhat.com>
When patching an OOT module, the symbol version file is obtained by
combining the file from the module build and the Module.symvers file
provided with kernel headers. This is done for each modified .o in the
OOT build.
Create the final Module.symvers file once for the whole OOT module.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
The modpost step complains about one of our generated files, output.o
and that it can't find a corresponding .cmd file for it (full path names
stripped):
WARNING: could not find .output.o.cmd for output.o
This was turned into an error in v5.8:
.output.o.cmd: No such file or directory
Avoid this by creating an empty .cmd file so that modpost acknowledges
that the file exists, but doesn't parse anything out of it.
Fixes#1125
Reported-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> (for v5.8+)
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Fail the kpatch build, while attempted to build on unsupported
architecture. The build will eventually fail but with the error that
doesn't hint the user clearly about the support status of kpatch, on the
architecture. This patch forces the build error with the message about
the unsupported status, avoiding confusion to the user.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Before kpatch-build would only keep build.log with --debug option
specified, but it also makes sense to keep it if --skip-cleanup is
specified.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
On x86, .altinstr_aux is used to store temporary code which allows
static_cpu_has() to work before apply_alternatives() has run. This code
is completely inert for modules, because apply_alternatives() runs
during module init, before the module is fully formed. Any changed
references to it (i.e. changed addend) can be ignored. As long as
they're both references to .altinstr_aux, they can be considered equal,
even if the addends differ.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Linux kernel tristate config options allows selected feature, either to
be built-in to the kernel or to be built as a kernel module. When built
as a kernel module, it's expected that the module, will be built with
module information such as author, license, description and others.
For each of the modinfo, a corresponding __UNIQUE_ID_ symbol is
generated. Their lookup succeeds in the case of module but fails when
selected to built-in to the kernel, the reason being that the kernel
discards these __UNIQUE_ID_ symbols during linking. Add __UNIQUE_ID_
symbols to maybe_discarded_sym list, to avoid failure in case of
table->object is vmlinux.
i.e.:
# cat .config|grep IOSCHED_BFQ (can be compiled as module too)
CONFIG_IOSCHED_BFQ=y
# readelf -sW ./block/bfq-iosched.o|grep UNIQUE
219: 0000000000000000 54 OBJECT LOCAL DEFAULT 267 __UNIQUE_ID_description223
220: 0000000000000036 16 OBJECT LOCAL DEFAULT 267 __UNIQUE_ID_license222
221: 0000000000000046 19 OBJECT LOCAL DEFAULT 267 __UNIQUE_ID_file221
222: 0000000000000059 25 OBJECT LOCAL DEFAULT 267 __UNIQUE_ID_author220
223: 0000000000000072 22 OBJECT LOCAL DEFAULT 267 __UNIQUE_ID_alias219
the line below before the kpatch error, is a debug printf to find the failing lookup symbol:
Failed lookup for __UNIQUE_ID_description223
/root/kpatch/kpatch-build/create-diff-object: ERROR: bfq-iosched.o: find_local_syms: 180: couldn't find matching bfq-iosched.c local symbols in ./vmlinux symbol table
with the patch, it successfully builds with both y/m config options:
...
bfq-iosched.o: changed function: bfq_idle_slice_timer
Patched objects: vmlinux
Building patch module:
livepatch-0001-block-bfq-fix-use-after-free-in-b.ko
SUCCESS
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
