kGraft — live kernel patching from SUSE

Posted Feb 3, 2014 22:16 UTC (Mon) by jhhaller (guest, #56103)
In reply to: kGraft — live kernel patching from SUSE by SEJeff
Parent article: kGraft — live kernel patching from SUSE

The biggest improvement to the state of the art in the ksplice-related tools was the ability to determine what actually changed in the kernel so that a minimal patch could be built automatically.

Live patching was a feature of telecom systems back in the 80's on a Unix base. Patching the kernel was the easy part. The hard part was patching shared libraries. Patches with data structure changes caused problems as well. Spare areas in structures and arrays were manually maintained and kept zeroed, so that they could be reallocated for a new piece of data. There was also a performance penalty, as all subroutine calls were indirect through a transfer vector, an array of jump tables. The entire array could be replaced, so that any particular process would only see the new functions when the process reentered its event loop.

Being able to live-patch the kernel without being able to live-patch shared libraries and long-running executables only addresses part of the problem. I expect that it would be valuable to clouds if the qemu process and it's libraries could be live-patched. But there will still be firmware to patched, and it's best to boot onto the new firmware when installed to be sure it works.

to post comments

kGraft — live kernel patching from SUSE

Posted Feb 4, 2014 4:10 UTC (Tue) by joyuh (guest, #95216) [Link] (6 responses)

You can just use live migration to migrate a VM to a new version of QEMU.

kGraft — live kernel patching from SUSE

Posted Feb 4, 2014 8:56 UTC (Tue) by pbonzini (subscriber, #60935) [Link] (4 responses)

That doesn't help with upgrading the kernel inside the VM.

kGraft — live kernel patching from SUSE

Posted Feb 4, 2014 9:54 UTC (Tue) by dgm (subscriber, #49227) [Link] (3 responses)

You could use something like LinuxPMI or OpenMOSIX to migrate processes to the new kernel.

In fact, an alternative method to update the kernel would be to boot a second kernel and migrate processes to it using this mechanism.

Maybe one day.

kGraft — live kernel patching from SUSE

Posted Feb 4, 2014 13:37 UTC (Tue) by ledow (guest, #11753) [Link] (2 responses)

So long as you don't mind using 2.6 kernels and/or not having 9 things that a process could do that might stop it migrating (such as using I/O directly, having a memory-mapped file, etc.).

There's plenty of reasons that something like ksplice would be superior under certain workloads than trying to revive a (dead) concept / software project.

kGraft — live kernel patching from SUSE

Posted Feb 4, 2014 22:11 UTC (Tue) by dgm (subscriber, #49227) [Link]

There are hurdles to doing it right now, but no fatal flaws in the concept. ksplice may be "superior under certain workloads", but process migration is a good design idea that will be implemented anyway on the long term.

kGraft — live kernel patching from SUSE

Posted Feb 6, 2014 17:54 UTC (Thu) by cov (guest, #84351) [Link]

CRIU can do this and is very much alive.

kGraft — live kernel patching from SUSE

Posted Feb 4, 2014 14:22 UTC (Tue) by jhhaller (guest, #56103) [Link]

Live migration has its limits, including a short period of time between when the VM stops on the old host, the last few memory updates are forwarded to the new host, and the VM starts again. For some applications, that time may be long enough to be considered downtime, even if it's a fraction of a second. Those are the applications which benefit from live patching and reduction in the number of events where software must be updated.