Interesting changes since v0.9.1:
- Integration test support for rhel-{7.8,7.9,8.1,8.2}, centos-8
- Better support for gcc child functions
- Batch jump label errors to report all instances
- Dynrela code cleanup
- Remove .klp.arch and add support for jump labels in v5.8+ kernels
- Mark ignored sections earlier to support functions missing ftrace hook
- Minor README.md improvements
- Add ppc64le mcount support to patched functions
- Show additional stalled process information in kpatch script
- Increased shellcheck coverage and fixes
- ppc64le plugin fixes for gcc v10
- Ignore __UNIQUE_ID_ symbol from tristate config objects
- Don't clear dmesg during integration tests
- Detect and report MODVERSIONS symbol version CRC changes
Signed-off-by: Joe Lawrence <joe.lawrence@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.
Increment version to v0.9.1 and update v0.9.0's changelog section
following many fixes and improvements.
*Note* that the tree has been tagged to v0.9.0 earlier at
(commit: fd8209aa00). This is to update the tree accordingly. Full
list of changes:
v0.9.1:
- Handle ppc64le toc with only constants
- Don't strip callback section symbols
- Integration tests update
- Fix -Wconversion warnings
- Process debug sections last
v0.9.0:
- Many fixes in integration tests and adding rhel-8.0
- Updates to documentation
- Many updates and additions to the patch author guide
- Fix to relocations used for ZERO_PAGE(0)
- Simplify static local variables correlation
- Make symvers reading code more flexible
- Free sections in elf teardown
- Fix kpatch-test module unloading
- Disable the build of kpatch.ko module by default
- Simplify mangled function correlation
- Use whole word filename matching in find_parent_obj()
- Simplify relocation processing
Signed-off-by: Yannick Cote <ycote@redhat.com>
A binary patch may be used to fix network-related issues, so it is better to
apply it before networking services have started.
We encountered a situation in Virtuozzo 7, when the older kernels
conflicted with a new NetworkManager, ip utility and other system
components (https://www.mail-archive.com/devel@openvz.org/msg35123.html).
Binary patches were provided for these kernels to fix the issue but were
loaded after networking services in some cases. As a result, NetworkManager
and some other system components failed to work properly.
Let us make sure the patches are applied earlier during boot.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Increment version to v0.8.0 due to manual signaling logic being removed
from kpatch util. Full list of changes:
- kpatch.ko atomic replace fixes
- Fixes for potential problems found by covscan
- Remove manual signaling logic from kpatch utility
- Don't strip callback symbols
- Allow dynamic debug static keys
Signed-off-by: Artem Savkov <asavkov@redhat.com>
- Fix several powerpc-specific bugs, including two which can result in
kernel panics
- Use rpmbuild --nodeps for installing srpm on Fedora/RHEL
- Fix inconsistent unit test failures for FAIL tests
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Increment version to v0.7.0 due to changed behavior of kpatch.service and
kpatch load subcommand. Full list of changes:
- Multiple memory leak fixes in kpatch-build
- livepatch-patch-hook compatability fixes for kernels 5.1+
- Making kpatch-build compatible with custom gcc names
- Added rhel-rebased integration tests
- kpatch.service will no longer unload modules on stop
- kpatch load will no longer fail if a module is already loaded and enabled
- kpatch-build will now check for *_fixup section changes on ppc64le and will
fail on such changes
- Add support for R_X86_64_PLT32
- don't allow jump labels
- ppc64le-specific kpatch-build fixes
Signed-off-by: Artem Savkov <asavkov@redhat.com>
The kpatch.service file shouldn't unload patch modules on service stop
(this is also executed by systemd on reboot). Patch modules may not be
designed to be safely unloaded and/or may patch kernel routines that
need to continue to run throughout system bring down.
Suggested-by: disaster123
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Create a minor release that includes fixes for:
- Lots of integration test work
- Better support for building out-of-tree modules
- Updated manpage options, drop deprecated distro specific mentions
- README.md updates for shadow variables, out-of-tree modules
- Fix core module compilation with CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
- kpatch-build detects and abort on unsupported options
GCC_PLUGIN_LATENT_ENTROPY, GCC_PLUGIN_RANDSTRUCT
- Fix patch linking with 4.20+
- Other minor shellcheck and kpatch-build fixups
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Create a minor release that includes fixes for:
- ppc64le: relax .text section addralign value check
- gcc8: unit-tests
- gcc8: support parent/child symbol relations
- gcc8: handle functions changing subsection
- gcc8: consider ".text.hot" sections bundleable
- kpatch-build: bugfix for less aggressive clean build-cache
- ubuntu: remove "-signed" substring from the kernel source package name
- ubuntu: explicitly note elfutils dependency
- upstream 4.18: unit-tests
- upstream 4.18: KCFLAGS -mcount-record support support
- RHEL-8: don't care who provides yumdownloader
- RHEL-8: account for quirky SRPM / release name conventions
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Create a minor release that includes fixes for:
* increase the transition timeout, helpful for large CPU count systems
* ppc64le WARN macro detection
* .parainstructions-related panic fix
* many, many unit/integration test cleanups and improvements
* properly align .parainstructions sections in patch module
* remove 'immediate' flag support from RHEL-7.6 onward
* initial GCC 8 support bugfixes
* support for RHEL kernel-alt release
* misc kpatch-build fixes and optimizations
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Increment version to 0.6.0 due to 926e4e0c7d ("kmod: add support for
in-kernel livepatch hooks"), which removed the kpatch (un)load hook API
support and converted to livepatch-style hooks.
Additional changes include:
* Lots of misc bugfixes and cleanups
* Manpage, README.md fixups
* More PPC64 work
* "Undefined reference" build failure rework
* Livepatch disable retries
* New unit testing framework
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Currently kpatch rely on systemd to load all kmods on startup.
This patch aims to enable kpatch to be used on upstart systems.
Limitations:
With systemd, it would be possible to unload all modules by issuing:
systemctl stop kpatch
It was not possible to make a reasonable upstart's equivalent of it, so
to unload the modules it will be necessary to call kpatch explicitly:
kpatch unload --all
I believe this it an non-issue, as it is still possible to unload
the modules by calling kpatch explicitly.
The file /etc/init/kpatch.conf will be installed unconditionally, and
removed on uninstall.
On my tests I have verified that all newly added files by this commit
are also deleted on uninstall.
It was also verified that applied patches are loaded again on startup.
rpmlint does not complain about anything new.
Signed-off-by: Bruno Loreto <loretob@amazon.com>
This release has many fixes and improvements since 0.3.4. The '0.3' was
bumped to '0.4' because of commit 0bb5c106ef ("kmod: restructure
kpatch sysfs tree"), which broke the ABI between the kpatch core module
and the kpatch script, as it changed the sysfs layout.
Other notable changes since 0.3.4:
- The tools underlying kpatch-build have been made more modular, in
preparation for making create-diff-object more generally useful to
other use cases (kernel livepatch, Xen live patching, user space
patching).
- Support for all new upstream kernels up to 4.10.
- KASLR support.
- Many other bug fixes and improvements.
It may be convenient to be able to turn off the automatic loading of
the patches that kpatch.service does. This helps, for example, if a
buggy patch is installed and crashes the system at boot.
This commit allows to specify kpatch.enable=0 in the kernel command
line. In this case, the binary patches will not be loaded automatically,
and the users should be able to remove or replace the offending patches
after the system boots.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Remove the dracut support for adding the kpatch modules to the
initramfs. This creates a sizeable delay in installation time and
doesn't offer any added protect over just applying the patches at boot
time using a systemd service. Additional, we are seeing more platforms,
namely atomic and netboot environments, where changing the initramfs
can't be done.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Use "inst" instead of "inst_symlink" for insmod, since insmod might not
necessarily be a symlink on some distros. inst_symlink is functionally
the same as inst, with an additional check to make sure that it's a
symlink (which we don't care about either way).
The "kpatch install" command is broken because the kpatch script has
some missing dependencies in the initramfs. Make sure the new
dependencies (readelf and awk) are added to the initramfs.
On RHEL I'm seeing issues with putting the core module in the "extra"
path. On the next depmod run, it gets added to modules.dep, and on a
subsequent kpatch install I see the following errors:
/usr/lib/dracut/modules.d/50drm/module-setup.sh: line 26: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
/usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh: line 14: /lib/modules/3.10.0-123.4.4.el7.x86_64//weak-updates/kpatch/kpatch.ko: No such file or directory
modinfo: ERROR: Module /lib/modules/3.10.0-123.4.4.el7.x86_64/weak-updates/kpatch/kpatch.ko not found.
Until the core module gets merged into Linux, I think we can put it in
/usr/lib/kpatch, which is also where the patch modules are going to be
delivered in the RHEL RPM.
Making sure the other options still work with the kpatch utility for
now, so as to keep backwards compatibility between a newer kpatch
utility and older core modules. We can break this compatibility for
kpatch 0.2.0.
The user-installed vs system-installed dichotomy is confusing. Let's
just have "installed". RPM-installed modules can just call "kpatch
install" in their post-install step.