Stories
Slash Boxes
Comments

SoylentNews is people

posted by CoolHand on Tuesday May 12 2015, @03:05AM   Printer-friendly
from the need-more-uptime dept.

Josh Boyer of the Fedora Project reports

[In Linux kernel 4.0], there is one feature that people (and various media sites) seem to have keyed in on and that is the live patching functionality. This holds the promise of being able to patch your running kernel without rebooting. Indeed, this could be very useful, but it isn't quite there yet. And it also doesn't make a whole lot of sense for Fedora at this time. The Fedora kernels have this functionality disabled, both in Fedora 22 and Rawhide.

What was merged for 4.0 is the core functionality that is shared between two live patching projects, kPatch and kGraft. kPatch is being led by a development team in Red Hat whereas kGraft is being developed by a team from SuSE. They both accomplish the same end result, but they do so via a different approach internally. The two teams met at the Linux Plumbers conference last year and worked on some common ground to make it easier to merge into mainline rather than compete with each other. This is absolutely awesome and an example of how new features should be developed upstream. Kudos to all those involved on that front.

The in-kernel code can accept patches from both methods, but the process and tools to create those patches are still being worked on in their upstream communities. Neither set are in Fedora itself, and likely won't be for some time as it is still fairly early in the life of these projects. After discussing this a bit with the live patching maintainer, we decided to keep this disabled in the Fedora kernels for now. The kernel-playground COPR does have it enabled for those that want to dig in and generate their own patches and are willing to break things and support themselves.

In reality, we might not ever really leverage the live patching functionality in Fedora itself.

Related: Kernel Live-Patching Moving into the Linux Kernel

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by Anonymous Coward on Tuesday May 12 2015, @06:13PM

    by Anonymous Coward on Tuesday May 12 2015, @06:13PM (#182033)

    They both have pros and cons. One of the interesting things to come out of the meetings between them is that a third hybrid system may actually be the best approach. As it stands currently, the kernel has 9 kernel patching systems (3 methods for stage 1 and 3 for stage 2).

    One important thing to realize is that this just delays reboots as opposed to getting rid of them completely. The reason is that every patched function hurts performance (with different methods having various degrees). But it does allow you to patch some critical bug or vulnerability now everywhere and reboot during downtime or stagger reboots without being worried about unpatched damage.

    Starting Score:    0  points
    Moderation   +3  
       Interesting=1, Informative=2, Total=3
    Extra 'Informative' Modifier   0  

    Total Score:   3