3

If the kernel is constantly in use by Ubuntu, how is it possible to modify it without a reboot?

3
  • 2
    see en.wikipedia.org/wiki/Kpatch
    – Rinzwind
    Jun 24, 2017 at 16:43
  • Could you please clarify how your question relates to Ubuntu since there's no official support for live kernel patching in it? Otherwise it's off topic on Ask Ubuntu. Jun 24, 2017 at 18:25
  • canonical-livepatch
    – user669400
    Jun 24, 2017 at 18:47

2 Answers 2

6

Servers or HPCs (High-Performance Computing) are intended to run on a 24x7x365 basis however because of basic security updates or OS updates, they must be restarted to apply the changes. Linux kernel live patching deals with this issue and keeps away from restarts.

Live patching begins with making a patch to change a particular kernel functionality. The patch can be made with a tool like kpatch-build. The outcome is a kernel module, which is then delivered. At the point when this module is loaded, it guarantees that the processes using a specific system call are using its patched form.

There are three kernel features that make the way of patching possible.

  • Kprobes:

    Kprobes or kernel probes is a feature used by developers to evaluate the Linux kernel and perform debugging. Kprobes enables developers to break into kernel routines at many code addresses. This is known as a breakpoint and enables the developer to make some move, for example, to run a new set of instructions.

  • Ftrace:

    The following element is called Function tracer or Ftrace. This is an amazing and powerful framework to measure several aspects within the kernel, like events and interrupts. For instance, it can measure the latency of particular functions like writing to disk.

  • Livepatch:

    Livepatch is the third segment. It is likewise the most recent expansion to the kernel. With a custom Ftrace handler, it can redirect routines and bounce to a patched set of instructions.

Live patching includes four essential operations that define the life cycle of each live patch.

  1. Registration:

    Each patch has first to be registered using klp_register_patch(). This makes the patch known to the live patch framework. After some initial figuring and checking, the patch is included into the list of of known patches. The addresses of the patched functions are found by their names. The special relocations, referenced in the segment 'New Functions', are applied. The applicable sections are made under /sys/kernel/livepatch/. The patch is dismissed when any operation fails.

  2. Enabling:

    Registered patches may be enabled either by calling klp_enable_patch() or by writing '1' to /sys/kernel/livepatch//enabled. The system will begin using the new implementation of the patched functions at this stage. Specifically, if an original function is patched fo the first time, a function-specific struct_klp_ops is created and a Ftrace handler is registered.

  3. Disabling :

    Enabled patches may get disabled either by calling klp_disable_patch() or by writing '0' to /sys/kernel/livepatch//enabled. At this stage, either the code from the recently enabled patch or even the original code gets used. Patches must be disabled in precisely the reverse order in which they were enabled. It makes taking care of the issue and the usage a lot simpler.

  4. Unregistration:

    Disabled patches may be unregistered by calling klp_unregister_patch(). This should be possible just when the patch is disabled and the code is never again used. It must be called before the live patch module gets unloaded.

To check if the live patch feature is enabled or not, run the following command:

cat /boot/config-$(uname - r) | grep LIVEPATCH
2

In brief, Live-patching was introduced in the v4.0 kernel, and Ubuntu 16.04 has a kernel capable of using this capability. This works by using ftrace to redirect kernel function calls to the newly patched functions. In addition, mechanisms for hooking into module insertion and removal are used for patching loadable modules. This feature also has sysfs directories for tracking which patches are applied and which functions they modify.

The simplest way to visualize this would be to treat live patching as a form of on-the-fly function substitution, while keeping track of what patch(es) was(or were) introduced to effect this change(s) via entries on sysfs.

You must log in to answer this question.