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>
Some theoretically unchanged functions can have undesired changes if the
compiler decides to perform inlining in a different way (e.g. because of
newly added references). In such a case, it can be useful to discard
changes to functions that don't actually need modification.
Sadly, this currently doesn't work for functions missing the ftrace hook
(e.g. notrace code) as presence of the hook is checked before
identifying elements to ignore.
Look for functions/sections to ignore earlier.
Signed-off-by: Julien Thierry <jthierry@redhat.com>
In shadow-newpid.patch, a new structure member is created using the
klp_shadow_get_or_alloc() routine. The simplified and explained version
of it in the patch author guide has a typo that replaces
klp_shadow_get_or_alloc() with klp_shadow_get().
Signed-off-by: Yannick Cote <ycote@redhat.com>
Replace module-call-external.patch with a more fleshed-out version which
tests multiple things (including jump tables for newer kernels), and
also includes a runtime test.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Starting with Linux 5.8, vmlinux-specific KLP relas are applied early,
before all the special section initializations are done.
This means that jump labels can now be supported for cases where the
corresponding static keys live in the core kernel (vmlinux).
It also means that paravirt patching and alternatives can also now be
supported without the need for the .klp.arch sections.
This simplifies things greatly for newer kernels. We just have to make
sure that module-specific KLP relas aren't created for special sections.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
There were a few kernels (4.7 and 4.8) which didn't have support for
.klp.arch sections, but for which we still tried to use
CONFIG_LIVEPATCH. Those are inherently buggy, so just drop
CONFIG_LIVEPATCH support for them altogether.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
kpatch.ko has been quietly deprecated for a while, because there are
some known issues, including special section initialization ordering
issues. Starting with Linux 5.7, it will be completely broken because
kallsyms_lookup_name() will no longer be exported.
Add a warning to make its deprecation status more obvious.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Do some kpatch-build script cleanups to improve readability. This
is only a cleanup and shouldn't affect any functionality.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
With Linux commit 5190044c2965 ("modpost: move the namespace field in
Module.symvers last"), the format of Module.symvers has changed yet
again.
Use a completely different approach for figuring out the format. If a
column has "vmlinux", assume that's the "Module" column.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
We have recently encountered a situation when a patched function
had more than one jump label (static branches with the same static key
used to turn on/off some debugging feature). As it is often the case
with jump labels, their locations were far from obvious in the source
code, hidden in the chains of inline functions.
create-diff-object, however, exits after it has reported one jump label.
This is inconvenient, because, after one updates the patch to avoid
that jump label, the next build of the binary patch reveals another
one and fails again, and so on. It can be very time-consuming.
Let us report all jump labels first.
Before this commit the messages looked like this:
kpatch-build/create-diff-object: ERROR: dev.o:
kpatch_regenerate_special_section: 2084:
Found a jump label at ploop_req_state_process()+0x220, using key css_stacks_on.
Jump labels aren't currently supported. Use static_key_enabled() instead.
After:
dev.o: Found a jump label at ploop_req_state_process+0x220, key: css_stacks_on.
dev.o: Found a jump label at ploop_ioctl+0x2708, key: css_stacks_on.
kpatch-build/create-diff-object: ERROR: dev.o:
kpatch_regenerate_special_section: 2123:
Found 2 jump label(s) in the patched code.
Jump labels aren't currently supported. Use static_key_enabled() instead.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
The dynrela (aka .klp.rela) conversion logic is notoriously complex and
fragile. Simplify it and improve the comments.
This is mainly a cosmetic change. In theory it shouldn't change
functionality or break anything.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
