Kernel live patching has been around since about 2010 through various forms in Linux distributions.

Even with Oracle’s ksplice and so on, there have been other people who has been using the live patch capabilities.

However, as a RH employee, I always had a more skeptical view on safety of it.

Recently I had a customer asking for more detailed information, and had a chance to do bit of research on this topic.

First Red Hat’s kpatch;
https://access.redhat.com/solutions/2206511

• It has formally released and supported from RHEL 8.1, RHEL 7.7; RHEL-7.6, and the kernel-3.10.0-957.35.1.el7.
• RH does not provide kpatch for all kernel patches but available for selected Important and Critical CVEs.
• Kpatch patches are cumulative. – You can’t pick and choose! – It means that when you get a new live kernel patch for the kernel, it will have all the fixes of the previous live kernel patch, along with the new fixes. You can safely upgrade the loaded live kernel patch to a newer version.
• Starting with RHEL 8.5 and kernel-3.10.0-1160.45.1.el, kernels will receive live kernel patches for 6 months. Therefore customers will need to upgrade the kernel and reboot at least twice per year.

How does kpatch work?

If you’re running a kernel version that supports it, you can (and should) take advantage of live kernel patching. This code execution method works alongside kernel probes and function tracing. Instead of relying on redirection using a breakpoint for kernel probes or a predefined location (in the case of function tracing), live patching is generally done by redirecting the code as close to the function entry as possible.

This new method allows for a function to be immediately redirected through a ftrace handler, so instead of calling an older, vulnerable function, it is redirected to a patched version of the function.

To reiterate it;
The kpatch kernel patching solution uses the livepatch kernel subsystem to redirect old functions to new ones. When a live kernel patch is applied to a system, the following things happen:

1. The kernel patch module is copied to the /var/lib/kpatch/ directory and registered for re-application to the kernel by systemd on next boot.
2. The kpatch module is loaded into the running kernel and the new functions are registered to the ftrace mechanism with a pointer to the location in memory of the new code.
3. When the kernel accesses the patched function, it is redirected by the ftrace mechanism which bypasses the original functions and redirects the kernel to patched version of the function.

What’s the differences between kpatch and other live kernel patch solution?

For kpatch vs kGraft, there has been detailed discussion at the linuxplumber conference in 2014.

https://blog.linuxplumbersconf.org/2014/wp-content/uploads/2014/10/LPC2014_LivePatching.txt

More to read:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/managing_monitoring_and_updating_the_kernel/index#applying-patches-with-kernel-live-patching_managing-monitoring-and-updating-the-kernel