Patching while running

Live patching means less reboots in Linux 4.0

Natali Vlatko
Patch image via Shutterstock

In the upcoming Linux 4.0, you may never need to reboot your operating system ever again – or at least, hardly ever. Live patching is coming, but apparently there are still a few hurdles to get through before we have full functionality.

After the recent announcement about Linux 4.0 and it’s new numbering pattern, what else can we look forward to in the next update? The latest changes to the Linux kernel could see live patching introduced, meaning you’ll need to reboot your operating system less often than ever.

Haven’t we seen this before?

Linux 4.0 isn’t breaking new ground by trying to introduce live patching – the option was available back in 2009 with Ksplice, which compared original and patched kernels, then used a customised kernel module to patch the new code into the running kernel.

However, with Oracle acquiring Ksplice in 2011 and keeping it for it’s own operating system, another option needed to be explored. While KernelCare offered a service that could provide bootless patches for most Linux distros, that required cash money for a monthly subscription.

Linux system administrators may already know that Red Hat and SUSE have both started work on an open-source solution for live patching, with the culmination of both technologies making up the live patching options in Linux 4.0. The collaboration was a result of a get together at last year’s Linux Plumbers Conference, where both companies had hoped to figure out a way to patch Linux without rebooting that combines the best of both programs.

In the end, the companies ended up putting both kpatch, Red Hat’s offering, and SUSE’s kGraft into the 4.0 Linux kernel. Very patching, much live.

A particularly rough patch

To throw a spanner in the works, Jonathan Corbet over at has delivered his own take on the headline feature, noting that work has only merely begun on the functionality and that more will be needed to have full support for live patching in the kernel:

Making this functionality work robustly on all systems would require a great deal of extra work to snapshot the full system state (including the state of devices) and restore it all under an arbitrarily different kernel.

Corbet has reported that combining the two technologies would hopefully combine the best of both and deliver a unified consistency model. In an attempt to produce this consistency, Josh Poimboeuf conceived an approach that retains the two-universe model from kGraft, but uses the stack-trace checking from kpatch to accelerate the task of switching processes to the new code.

Corbet explains that in theory this technique “increases the chances of successfully applying patches while doing away with kpatch’s disruptive stop_machine() call and much of kGraft’s higher code complexity”, but objections to the use of stack traces have been raised by Hungarian Linux hacker Ingo Molnar:

[T]here’s no strong force that ensures we can rely on stack backtraces: correcting bad stack traces depends on people hitting those functions and situations that generate them, seeing a bad stack trace, noticing that it’s weird and correcting whatever code or tooling quirk causes the stack entry to be incorrect.

Work is still progressing to ensure that the kernel will have an essentially complete live-patching feature by the end of the year.

Natali Vlatko
An Australian who calls Berlin home, via a two year love affair with Singapore. Natali was an Editorial Assistant for (S&S Media Group).

Inline Feedbacks
View all comments