Live Patching Now Available For Linux

New submitter cyranix writes "You may never have to reboot your Linux machine ever again, even for kernel patching," and excerpts from the long (and nicely human-readable) description of newly merged kernel code that does what Ksplice has for quite a while (namely, offer live updating for Linux systems, no downtime required), but without Oracle's control. It provides a basic infrastructure for function "live patching" (i.e. code redirection), including API for kernel modules containing the actual patches, and API/ABI for userspace to be able to operate on the patches (look up what patches are applied, enable/disable them, etc). It's relatively simple and minimalistic, as it's making use of existing kernel infrastructure (namely ftrace) as much as possible. It's also self-contained, in a sense that it doesn't hook itself in any other kernel subsystem (it doesn't even touch any other code). It's now implemented for x86 only as a reference architecture, but support for powerpc, s390 and arm is already in the works (adding arch-specific support basically boils down to teaching ftrace about regs-saving).

Comments

Discussed in the Kernel Report

[rgbe]

This, among other things was discussed in the Kernel Report, at the recent Linux Conf in Auckland, New Zealand:
  https://www.youtube.com/watch?...

Re:Discussed in the Kernel Report

[buchner.johannes]

at 39:39

No more downtime

[ArcadeMan]

Which means you can keep it up forever!

(PHRASING!)

Re:No more downtime

[gavron]

Ok, so here's the simple answer. Note: I'm generalizing a lot to make this simple.

All functions have a known entry point which you can think of a name that you can call like
print("hello world"); -- calls "print" so it knows where "print" is.

Somewhere in the memory was loaded the function print(). There's also a symbol which allows everyone who wants to call print() to know where it is.

The livepatch loads a new function into memory. Let's call it print2(). It then goes over and makes the symbol that used to let everyone know where print() is point to print2(). Anyone that comes after this patch will still think they are calling print() but in fact will be calling print().

The stop_machine() is part of how ksplice (the proprietary-vendor method does it). That is not part of kernel live patch (klp).

What klp does is ensure that a process is in a "good point" to be messed with, and then changes its pointer to e.g. print().

That allows no changes to affect the process until that pointer to print() is changed at which point any subsequent call to print() will run print() instead.

Ehud
P.S. I have some code from the early 1990s where we used to do this on VMS/OpenVMS. We literally patched the running kernel (much as is done here) and allowed a system to run for years with newer kernel code.

Time to update the ol' t-shirt...

[DigitAl56K]

... to a more extreme version:

"I don't always test my code, but when I do it's via live patching the kernel on production"

Re:Sounds great

[bill_mcgonigle]

I can't possibly see this ever causing a problem with this because linux is very secure and there is absolutely no way for a malicious user to get elevated access on anything that runs linux. This includes android phones, which are totally invulnerable to hacking.

You should suggest to Linus that he make kernel features configurable so people can do different builds for different targets. Put it in a dot-config file or something. Maybe in a future release...

Unintended consequences?

[marciot]

Maybe I’m old school, but this sort of bothers me. One of the nice things about rebooting is that it clears out old crud and gives you a reassurance that the system can bring itself up by its bootstraps. I can imagine live patching giving rise to a scenario where you have a machine that hasn’t been rebooted for years and when a power glitch finally brings it down, you find that what is on disk is different than what was in RAM and your kernel is corrupt or not bootable.

I think live patching would make sense if we had non-volatile system RAM (i.e. universal memory), but until then, it seems like rebooting is a pretty good sanity check that things are alright.