NOTICE: kpatch is deprecated
[!IMPORTANT]
NOTICE: The kpatch project is in maintenance mode
Starting with Linux 6.19, the kpatch project is deprecated and in maintenance mode. kpatch-build functionality is being replaced by klp-build, which is now part of the upstream Linux kernel.
klp-build architecture support:
- x86-64: supported (Linux 6.19+)
- arm64: patches in development on LKML
- ppc64le, s390, loongarch: coming soon
What this means for kpatch:
- kpatch is now in maintenance mode.
- No new features will be added.
- Bug fixes for newer kernels or toolchains will not be provided.
- Existing functionality for older kernels continues to work and will be maintained minimally as needed.
Questions?
- For more information, see issue 1498.
kpatch is a Linux dynamic kernel patching infrastructure which allows you to patch a running kernel without rebooting or restarting any processes. It enables sysadmins to apply critical security patches to the kernel immediately, without having to wait for long-running tasks to complete, for users to log off, or for scheduled reboot windows. It gives more control over uptime without sacrificing security or stability.
WARNING: Use with caution! Kernel crashes, spontaneous reboots, and data loss may occur!
Here's a video of kpatch in action: And a few more:
See INSTALL.md.
NOTE: While kpatch is designed to work with any recent Linux kernel on any distribution,
kpatch-buildhas specifically been tested and confirmed to work on Fedora and RHEL. It has also been known to work on Oracle Linux, Ubuntu, Debian, and Gentoo.
First, make a source code patch against the kernel tree using diff, git, or quilt.
As a contrived example, let's patch /proc/meminfo to show VmallocChunk in ALL CAPS so we can see it better:
$ cat meminfo-string.patch
Index: src/fs/proc/meminfo.c
===================================================================
--- src.orig/fs/proc/meminfo.c
+++ src/fs/proc/meminfo.c
@@ -95,7 +95,7 @@ static int meminfo_proc_show(struct seq_
"Committed_AS: %8lu kB\n"
"VmallocTotal: %8lu kB\n"
"VmallocUsed: %8lu kB\n"
- "VmallocChunk: %8lu kB\n"
+ "VMALLOCCHUNK: %8lu kB\n"
#ifdef CONFIG_MEMORY_FAILURE
"HardwareCorrupted: %5lu kB\n"
#endif
Build the patch module:
$ kpatch-build meminfo-string.patch
Using cache at /home/jpoimboe/.kpatch/3.13.10-200.fc20.x86_64/src
Testing patch file
checking file fs/proc/meminfo.c
Building original kernel
Building patched kernel
Detecting changed objects
Rebuilding changed objects
Extracting new and modified ELF sections
meminfo.o: changed function: meminfo_proc_show
Building patch module: livepatch-meminfo-string.ko
SUCCESS
That outputs a patch module named kpatch-meminfo-string.ko in the current
directory. Now apply it to the running kernel:
$ sudo kpatch load kpatch-meminfo-string.ko
loading patch module: livepatch-meminfo-string.ko
Done! The kernel is now patched.
$ grep -i chunk /proc/meminfo
VMALLOCCHUNK: 34359337092 kB
Unfortunately, live patching isn't always as easy as the previous example, and can have some major pitfalls if you're not careful. To learn more about how to properly create live patches, see the Patch Author Guide.
kpatch works at a function granularity: old functions are replaced with new ones. It has three main components:
kpatch-build: a collection of tools which convert a source diff patch to a patch module. They work by compiling the kernel both with and without the source patch, comparing the binaries, and generating a patch module which includes new binary versions of the functions to be replaced.
patch module: a kernel livepatch module (.ko file) which includes the replacement functions and metadata about the original functions. Upon loading, it registers itself with the kernel livepatch infrastructure (CONFIG_LIVEPATCH) which does the patching.
kpatch utility: a command-line tool which allows a user to manage a collection of patch modules. One or more patch modules may be configured to load at boot time, so that a system can remain patched even after a reboot into the same version of the kernel.
The "kpatch-build" command converts a source-level diff patch file to a kernel
patch module. Most of its work is performed by the kpatch-build script
which uses a utility named create-diff-object to compare changed objects.
The primary steps in kpatch-build are:
-ffunction-sections -fdata-sections,
resulting in the changed patched objects-ffunction-sections -fdata-sections,
resulting in the changed original objectscreate-diff-object to do the following:.kpatch.funcs and .rela.kpatch.funcs sections to the output object.
The kpatch core module uses this to determine the list of functions
that need to be redirected using ftrace..kpatch.dynrelas and .rela.kpatch.dynrelas sections to the output object.
This will be used to resolve references to non-included local
and non-exported global symbols. These relocations will be resolved by the kpatch core module.NOTE: Many of these limitations can be worked around with creative solutions. For more details, see the Patch Author Guide.
Patches which modify init functions (annotated with __init) are not
supported. kpatch-build will return an error if the patch attempts
to do so.
Patches which modify statically allocated data are not directly supported. kpatch-build will detect that and return an error. This limitation can be overcome by using callbacks or shadow variables, as described in the Patch Author Guide.
Patches which change the way a function interacts with dynamically allocated data might be safe, or might not. It isn't possible for kpatch-build to verify the safety of this kind of patch. It's up to the user to understand what the patch does, whether the new functions interact with dynamically allocated data in a different way than the old functions did, and whether it would be safe to atomically apply such a patch to a running kernel.
Patches which modify functions in vdso are not supported. These run in user-space and ftrace can't hook them.
Patches which modify functions that are missing a fentry call are not
supported. This includes any lib-y targets that are archived into a
lib.a library for later linking (for example, lib/string.o).
Some incompatibilities currently exist between kpatch and usage of ftrace and kprobes. See the Frequently Asked Questions section for more details.
Q. Isn't this just a virus/rootkit injection framework?
kpatch uses kernel modules to replace code. It requires the CAP_SYS_MODULE
capability. If you already have that capability, then you already have the
ability to arbitrarily modify the kernel, with or without kpatch.
Q. How can I detect if somebody has patched the kernel?
If a patch is currently applied, you can see it in /sys/kernel/livepatch.
Also, if a patch has been previously applied, the TAINT_LIVEPATCH flag is
set. To test for these flags, cat /proc/sys/kernel/tainted and check to see
if the value of TAINT_LIVEPATCH (32768) has been OR'ed in.
Note that the TAINT_OOT_MODULE flag (4096) will also be set, since the patch
module is built outside the Linux kernel source tree.
If your patch module is unsigned, the TAINT_UNSIGNED_MODULE flag (8192) will
also be set.
Q. Will it destabilize my system?
No, as long as the patch is created carefully. See the Limitations section above and the Patch Author Guide.
Q. Why not use something like kexec instead?
If you want to avoid a hardware reboot, but are ok with restarting processes or using CRIU, kexec is a good alternative.
Q. If an application can't handle a reboot, it's designed wrong.
That's a good poi... [system reboots]
Q. What kernels are supported?
kpatch needs gcc >= 4.8 and Linux >= 4.0.
Q. Is it possible to remove a patch?
Yes. Just run kpatch unload which will disable and unload the patch module
and restore the function to its original state.
Q. Can you apply multiple patches?
Yes, but to prevent any unexpected interactions between multiple patch modules,
it's recommended that patch upgrades are cumulative, so that each patch is a
superset of the previous patch. This can be achieved by combining the new
patch with the previous patch using combinediff before running
kpatch-build. It's also recommended to use livepatch atomic "replace" mode,
which is the default.
Q. Why did kpatch-build detect a changed function that wasn't touched by the source patch?
There could be a variety of reasons for this, such as:
__LINE__ macro usage.Q. Are patching of kernel modules supported?
Q. Can you patch out-of-tree modules?
Yes! There's a few requirements, and the feature is still in its infancy.
--oot-module flag to specify the version of the
module that's currently running on the machine.--oot-module-src has to be passed with a directory containing the same
version of code as the running module, all set up and ready to build with a
make command. For example, some modules need autogen.sh and
./configure to have been run with the appropriate flags to match the
currently-running module.Module.symvers file for the out-of-tree module doesn't appear
in the root of the provided source directory, a symlink needs to be created
in that directory that points to its actual location.--target flag as well, to specify the
proper make target names.No open issues yet, or sync has not completed.