Servers, systems or HPCs are meant to run on a 24x7x365 basis but due to critical security updates or OS updates, they have to be restarted to apply the changes. Linux kernel live patching takes care of this issue and avoids restarts.
Live patching starts with making a patch to change a specific kernel function. The patch can be created with a tool like kpatch-build. The result is a kernel module, which is then distributed. When this module is loaded, it ensures that processes using a particular system call are using its patched version, a process that is somewhat similar to a traffic diversion.
There are three kernel features that make the process of patching possible.
Kprobes: Kprobes or kernel probes is a feature used by developers to assess the Linux kernel and perform debugging. Kprobes allows developers to break into kernel routines at many code addresses. This is called a breakpoint and allows the developer to take some action, such as to run a new set of instructions.
Ftrace: The next feature is called function tracer or Ftrace. This is a powerful framework to measure several aspects within the kernel, like events and interrupts. For example, it can measure the latency of specific functions like writing to disk.
Livepatch: Livepatch is the third component. It is also the latest addition to the kernel. With a custom Ftrace handler, it can redirect routines and jump to a patched set of instructions.
The life cycle of a live patch
Live patching involves four basic operations that define the life cycle of each live patch.
Registration: Each patch has first to be registered using klp_register_patch(). This makes the patch known to the live patch framework. After some preliminary computing and checking, the patch is added into the list of known patches. The addresses of the patched functions are found according to their names. The special relocations, mentioned in the section ‘New functions’, are applied. The relevant entries are created under /sys/kernel/livepatch/<name>. The patch is rejected when any operation fails.
Enabling: Registered patches might be enabled either by calling klp_enable_patch() or by writing ‘1’ to /sys/kernel/livepatch/<name>/enabled. The system will start using the new implementation of the patched functions at this stage. In particular, if an original function is patched for the first time, a function-specific struct klp_ops is created and a universal Ftrace handler is registered.
Disabling: Enabled patches might get disabled either by calling klp_disable_patch() or by writing ‘0’ to /sys/kernel/livepatch/<name>/enabled. At this stage, either the code from the previously enabled patch or even the original code gets used.
Patches must be disabled in exactly the reverse order in which they were enabled. It makes solving the problem and the implementation much easier.
Unregistration: Disabled patches might be unregistered by calling klp_unregister_patch(). This can be done only when the patch is disabled and the code is no longer used. It must be called before the live patch module gets unloaded.
Live patching has several limitations. Some of them are:
- Traceable functions only can be patched.
- Kretprobes using the Ftrace framework conflict with the patched functions.
- Kprobes in the original function are ignored when the code is redirected to the new implementation.
OS variants of kernel live patching are:
Use case of the Ubuntu live patch
Canonical Livepatch Service: This applies critical kernel patches without rebooting.
- Fixes are applied automatically, without restarting your system.
- It reduces downtime, keeping your Ubuntu LTS systems secure and compliant.
- The service is included as part of all Ubuntu Advantage for Infrastructure support packages.
- It is free for three machines.
- All you need is an Ubuntu One account. To check if the live patch feature is enabled or not, run the following command:
$cat /boot/config-$(uname -r) | grep LIVEPATCH
To check the current live patch status, run the command given below:
The author is a senior technical officer at ICT & Services, CDAC, Kolkata. He has over ten years of industry experience, and his areas of interest include Linux system administration, mobile forensics and Big Data. He can be reached at firstname.lastname@example.org.