I am trying to understand a new concept I got to know recently as the Linux 4.0 makes it way to the mainline - "Live Patching".

Supposedly this is a new feature enhancement of the Linux kernel. It was first developed independently by Red Hat and Open SUSE about a year ago.

I know, any feature developments/bug fixes are generally implemented in the Linux kernel via patches, i.e., you apply the patch for the concerned Linux kernel version, Re-Compile the Kernel Source and install it via usual methods of $make;sudo make install.

The interesting part of the supposedly "live patching" mechanism is that, you won't have to re-compile and install a new kernel version?. I Mean, your GRUB won't show an entry to a newer kernel version right?, because you didn't make install one.

Now, this is some serious concept to digest for me. How is it possible even?, How would it be implemented?.

Red Hat and Open SUSE use the Kpatch and kGraft respectively to implement it.

I would like to try out a simple kernel module, and use one of Kpatch or kGraft to implement it. But I have an Ubuntu 14.04 system, any alternative for Ubuntu?

The closest that I came to understanding this new concept is, you would need to write and compile the patch in a new framework (like ftrace). So, you would have the API/ABI from the user-space just redirected from the "faulty" kernel module to the newer API/ABI implementation that you just installed using this patch (how would one "just" install a patch which is built in a special framework?). Am I right here?

If anyone who is a Linux kernel expert knows about this, I would love to hear from you what this "live patching" is all about and how would one go about creating a live patch and then, how would the user of the system, install this patch and verify it's functionality (test it)?

Along with understanding this concept, I would like to know how to program such a "live patch"?. And what all environment would I need to do so too?

closed as off-topic by terdon Oct 29 '15 at 23:38

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question has been posted on multiple sites. Cross-posting is strongly discouraged; see the help center and community FAQ for more information." – terdon

  • 1
    "First developed about a year ago"? This has been around in ksplice since 2008. Where did you get that piece of misinformation? – Anthon Apr 1 '15 at 12:38
  • I didn't know about ksplice. I read about about Kpatch and kGraft, they were released about a year ago. – Yusuf Husainy Apr 2 '15 at 5:35

If the kernel is not a complete rewrite (with function names changed etc, reordering of parameters passed into functions), you can analyse the binaries of the original kernel and the patched kernel, and see which functions changed.

Then you overwrite the start of a changed routine to jump to a changed version of the routine that you have loaded into memory. This is done while no other processes are running.

The wikipedia article on ksplice explains this more detailed in an understandable way.

You can of course try to program a patch, and come up with smaller patches (chaning a few lines of machine code, instead of full functions). Such smaller patches require that you carefully jump back in the original routine instead of just returning from your patched function call.

Patching the grub menu to have a new version number is easy compared to the analysis and patching of the kernel binaries. That menu is text only. But the idea is that you never will see the grub menu after the first boot up anyway.

This might be a new feature in Red Hat and Open SuSE, but it is not invented only a year ago, as e.g. ksplice started patching running kernels back in 2008. The concept of patching a program (not necessarily the Linux kernel) in memory is much older. I have used patching of programs in memory based on manual analysis myself as early as 1984 (patching 6502 machine code), and I certainly did not come up with the idea to do so myself at that time.

Not the answer you're looking for? Browse other questions tagged or ask your own question.