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>
Kernel livepatching modules build on GCC 10, with patched functions
referring to local function would fail to load with the error:
module_64: livepatch_ext4_cond_resched: Expected nop after call, got 7fe5fb78 at ext4_setup_system_zone+0x460/0xc90 [livepatch_ext4_cond_resched]
for more details on the error, refer to discussion at:
https://lkml.kernel.org/r/1508217523-18885-1-git-send-email-kamalesh@linux.vnet.ibm.com
the reason was that the gcc-plugin would skip the pass on error, failing
to convert the local calls into global, i.e on ppc64le every global call
is followed by a nop instruction, that gets replaced by the kernel to
restore
the TOC/r2 value of the callee, while parsing the relocations and would
skip the TOC restoration for local functions, where the TOC remains the
same across sibling functions.
GCC 10 commit 07c48b61a082("[RS6000] Put call cookie back in AIX/ELFv2
call patterns") merged a couple of call codes definition, breaking the
plugin. Change the plugin codes to match the GCC 10 codes.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Abort building the klp module, if the code for local and non-local calls
are not found instead of skipping the pass and building module, which
might result in un-loadable module with the kernel error:
module_64: livepatch_ext4_cond_resched: Expected nop after call, got 7fe5fb78 at ext4_setup_system_zone+0x460/0xc90 [livepatch_ext4_cond_resched]
gcc would not allow me to use "can't" in the error message and throw
build error:
gcc-plugins/ppc64le-plugin.c:49:17: error: contraction ‘can't’ in format; use ‘cannot’ instead [-Werror=format-diag]
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Building on Fedora 32 with GCC 10.1.1, triggers build failures:
In file included from gcc-plugins/ppc64le-plugin.c:1:
gcc-plugins/gcc-common.h:37:10: fatal error: params.h: No such file or directory
37 | #include "params.h"
| ^~~~~~~~~~
compilation terminated.
In file included from gcc-plugins/ppc64le-plugin.c:1:
gcc-plugins/gcc-common.h:841:13: error: redefinition of ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’
841 | inline bool is_a_helper<const ggoto *>::test(const_gimple gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from gcc-plugins/gcc-common.h:124,
from gcc-plugins/ppc64le-plugin.c:1:
/usr/lib/gcc/ppc64le-redhat-linux/10/plugin/include/gimple.h:1037:1:
note: ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here
1037 | is_a_helper <const ggoto *>::test (const gimple *gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from gcc-plugins/ppc64le-plugin.c:1:
gcc-plugins/gcc-common.h:848:13: error: redefinition of ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const greturn*]’
848 | inline bool is_a_helper<const greturn *>::test(const_gimple gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from gcc-plugins/gcc-common.h:124,
from gcc-plugins/ppc64le-plugin.c:1:
/usr/lib/gcc/ppc64le-redhat-linux/10/plugin/include/gimple.h:1489:1:
note: ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const greturn*]’ previously declared here
1489 | is_a_helper <const greturn *>::test (const gimple *gs)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
as per kernel commit c7527373fe28 ("gcc-common.h: Update for GCC 10")
"params.h header file has been dropped from GCC 10 and is_a_helper()
macro is now defined in gimple.h"
this patch fix them by guarding the both param.h header file and
is_a_helper() with #ifdef checking for gcc version < 10000.
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Fixing the remaining warnings suggesting to quote the output subshell
invocation would hinder readability. Also the results of dirname and
"type -p" used in the subshell should return spaceless strings in kpatch
usecases.
Ignore the warnings for now.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
It wouldn't be bash without pondering over what to quote or not to
quote.
Shellcheck reports a bunch of quoting issues in our scripts. Fix what
can be fixed.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Shellcheck emits the following warning:
SC2044: For loops over find output are fragile. Use find -exec or a while read loop.
Disable it for now.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Shellchecks warns about two useless commands:
SC2005: Useless echo? Instead of 'echo $(cmd)', just use 'cmd'.
SC2002: Useless cat. Consider 'cmd < file | ..' or 'cmd file | ..' instead.
Simplify that line with those suggestions.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Shellcheck emmits the following warning:
SC2035: Use ./*glob* or -- *glob* so names with dashes won't become options.
Which seems like a fair recommendation.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Shellcheck reports the following error:
SC2145: Argument mixes string and array.
Lets pretend that types are a thing in bash and use the list of
arguments as a single string instead of the array of arguments.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Shellcheck complains with the following warning:
SC2230: which is non-standard.
It is probably fair to assume that which is available for now, so just
ignore the warning.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Shellcheck complains with the following warning:
SC1091: Not following: /etc/os-release was not specified as input (see shellcheck -x)
Which is already silenced in lib.sh.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
A bash script is available to automatically install necessary
dependencies for building/using kpatch on some distributions.
Update the README sections for those distributions to use that script.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
On RHEL-8, version agnostic python-devel package does not exist.
On previous RHEL releases, python-devel is for python2.
On RHEL-8, the platform-python (which provides the needed utilities)
is python3.
Assuming this will be the same for future RHEL releases, specify the
python major as part of the kpatch dependencies.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
Enable dynamic debug prints in klp_try_switch_task() function before
going through with load tests and switch back to a previous state
afterwards.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
For consistency, disable the shadow-newpid-LOADED integration test
script since its corresponding patch already is already disabled.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Add the __mcount_loc section on ppc64le. It has pointers to all the
mcount calls. This will enable the ftrace hook to be used for patched
functions.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com> (rebased)
Patches rebased against RHEL-8.2 GA kernel-4.18.0-193.el8.
Tests disabled for errors when building against updated
4.18.0-193.3.1.el8_2.x86_64 z-stream kernel:
* data-read-mostly.patch:
dev.o: Found a jump label at __netif_receive_skb_core()+0x32, using key netstamp_needed_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
dev.o: Found a jump label at __netif_receive_skb_core()+0x95, using key generic_xdp_needed_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
dev.o: Found a jump label at __netif_receive_skb_core()+0xd0, using key ingress_needed_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
dev.o: Found a jump label at __netif_receive_skb_core()+0x412, using key nf_hooks_needed. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
/root/github-kpatch/kpatch-build/create-diff-object: ERROR: dev.o: kpatch_regenerate_special_section: 2344: Found 4 jump label(s) in the patched code. Jump labels aren't currently supported. Use static_key_enabled() instead.
* gcc-static-local-var-4.patch (ppc64le only):
aio.o: Found a jump label at aio_free_ring()+0x7c, using key devmap_managed_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
/root/github-kpatch/kpatch-build/create-diff-object: ERROR: aio.o: kpatch_regenerate_special_section: 2344: Found 1 jump label(s) in the patched code. Jump labels aren't currently supported. Use static_key_enabled() instead.
* shadow-newpid.patch:
fork.o: WARNING: unable to correlate static local variable ctr.70325 used by _do_fork, assuming variable is new
fork.o: changed function: _do_fork
exit.o: Found a jump label at do_exit()+0x6d3, using key devmap_managed_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
/root/github-kpatch/kpatch-build/create-diff-object: ERROR: exit.o: kpatch_regenerate_special_section: 2344: Found 1 jump label(s) in the patched code. Jump labels aren't currently supported. Use static_key_enabled() instead.
* special-static.patch:
fork.o: Found a jump label at copy_process.part.34()+0x1fc, using key memcg_kmem_enabled_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
fork.o: Found a jump label at copy_process.part.34()+0x21b, using key memory_cgrp_subsys_enabled_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
fork.o: Found a jump label at copy_process.part.34()+0x72a, using key memory_cgrp_subsys_enabled_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead.
fork.o: Found a jump label at copy_process.part.34()+0x773, using key memcg_kmem_enabled_key. Jump labels aren't supported with this kernel. Use static_key_enabled() instead
./root/github-kpatch/kpatch-build/create-diff-object: ERROR: fork.o: kpatch_regenerate_special_section: 2344: Found 4 jump label(s) in the patched code. Jump labels aren't currently supported. Use static_key_enabled() instead.
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Or, to be exact, with addend values which cannot be represented by
a signed int variable.
This only applies to the old KPatch core.
Commit 15067fcd "kmod/core: apply dynrela addend for R_X86_64_64" fixed
calculation of the values for R_X86_64_64 dynrelas. This revealed
another issue, similar to https://github.com/dynup/kpatch/issues/1064.
Dynrelas are stored as 'struct kpatch_patch_dynrela' instances in the
patch module but both the patch module and kpatch.ko use
'struct kpatch_dynrela' to work with the dynrelas. 'addend' has type
'long' in kpatch_patch_dynrela but 'int' in kpatch_dynrela, so this
value can be truncated when read.
R_X86_64_64 dynrela can be created, for example, if a patch for vmlinux
refers to something like '(unsigned long)&idt_table+0x80000000' (a global
variable which is not exported, with some addend).
The addend == +0x80000000, however, effectively becomes 0xffffffff80000000
(== -0x80000000) due to this bug.
Unfortunately, 'struct kpatch_dynrela' is a part of the ABI between
kpatch.ko and patch modules. Plain changing 'int addend' into 'long addend'
there could be problematic. The patch module built using the new
'struct kpatch_dynrela' will either fail to load if kpatch.ko is using the old
'struct kpatch_dynrela' or cause crashes or data corruptions. Unloading
and reloading patch modules and kpatch.ko is not always an option
either.
Luckily, R_X86_64_64 dynrelas seem to be quite rare in the production
patch modules and R_X86_64_64 dynrelas with large addends are expected
to be even more rare.
So, instead of fixing the truncation of addends right away, I propose to
detect it, for now, when building a patch. If one never hits such conditions,
it is not worth it to fix the issue. If R_X86_64_64 dynrelas with large
addends do happen and cannot be avoided, we can try to figure out how to
fix this properly, without breaking too much.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Since the kernel we were testing against before is no longer available
in centos repos I've updated our test vagrant image bringing the kernel
version to 3.10.0-1127.el7. Since this is basically the rhel-7.8 kernel
and we don't want extra work maintaining extra sets of patches just
symlink centos-7 patch directory to rhel-7.8. If(when) we are in this
situation again we'll just switch the symlink to the appropriate minor
again.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
Prior to this commit, the kpatch.spec was not building because of #1042.
The kernel module is not built by default, but the spec was not updated accordingly.
With this commit, the kpatch.spec supports building the module or not using a %bcond.
Like the Makefile, it does not build the module by default.
User stettberger noticed that the kpatch support module does not
apply the addend for R_X86_64_64 in kpatch_write_relocations().
The AMD64 ABI draft doc [1], Table 4.10: Relocation Types lists that
relocation type as:
Name Value Field Calculation
R_X86_64_64 1 word64 S + A
where:
S : Represents the value of the symbol whose index resides in the
relocation entry.
A : Represents the addend used to compute the value of the relocatable
field.
[1] http://refspecs.linuxfoundation.org/elf/x86_64-abi-0.99.pdfFixes: #1093
Reported-by: Christian Dietrich <stettberger@dokucode.de>
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
ppc64le build currently fails dues to unused sched_clock variable. Move
it's declaration into ifdef block.
Signed-off-by: Artem Savkov <asavkov@redhat.com>
