Announcement

Collapse
No announcement yet.

Red Hat Intros Kpatch For Dynamic Kernel Patching

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Red Hat Intros Kpatch For Dynamic Kernel Patching

    Phoronix: Red Hat Intros Kpatch For Dynamic Kernel Patching

    Red Hat's latest open-source contribution to the Linux community is Kpatch, yet another means of dynamic patching for the Linux kernel...

    http://www.phoronix.com/vr.php?view=MTYyMTE

  • #2
    inb4 both RH and Suse solutions get upstream, and a rootkit uses each to patch the other out at runtime.

    Comment


    • #3
      Why do we need 3 of them?

      Comment


      • #4
        Ksplice, Kgraft and now Kpatch.

        NIH syndrome at its best. And i'll bet that Kpatch eventually gets upstreamed just because it's from Red Hat.

        Comment


        • #5
          Originally posted by Sonadow View Post
          Ksplice, Kgraft and now Kpatch.

          NIH syndrome at its best. And i'll bet that Kpatch eventually gets upstreamed just because it's from Red Hat.
          if kpatch gets upstreamed that's because it's the best solution. not just because it was developed by redhat - that's how it works.

          I would not be surprised if the code that will be merged upstream would not contain parts from both kgraft an kpatch.

          Comment


          • #6
            Originally posted by Sonadow View Post
            Ksplice, Kgraft and now Kpatch.

            NIH syndrome at its best. And i'll bet that Kpatch eventually gets upstreamed just because it's from Red Hat.
            Yes because linux kernel development has never duplicated effort until the developers reach a consensus and one is chosen.
            We must observe this phenomena closely!

            Comment


            • #7
              I never really understood why anyone would want to do this. I would think, even on systems that need to maximize up time, you would want to do scheduled maintenance once in a while. This way you know exactly how the system will behave on shutdown/startup so when unintended downtime occurs you aren't blindsided by something odd.

              Comment


              • #8
                Originally posted by svanheulen View Post
                I never really understood why anyone would want to do this. I would think, even on systems that need to maximize up time, you would want to do scheduled maintenance once in a while. This way you know exactly how the system will behave on shutdown/startup so when unintended downtime occurs you aren't blindsided by something odd.
                I guess this is for security patches, that would be applied outside scheduled maintenance. Also, I'd like that on my desktop, so I don't restart, ever :P


                Does anyone knows the main differences/advantages between the three proposed systems?

                Comment


                • #9
                  Originally posted by svanheulen View Post
                  I never really understood why anyone would want to do this. I would think, even on systems that need to maximize up time, you would want to do scheduled maintenance once in a while. This way you know exactly how the system will behave on shutdown/startup so when unintended downtime occurs you aren't blindsided by something odd.
                  Kpatch is what you would use in the time between an issues discovery and the scheduled maintenance. Most enterprises have some sort of change management that has the following change management tiers:

                  1: Incident response -- (we're down, being actively exploited, etc, etc)
                  2: Emergency change -- (we could go down, are vulnerable, etc etc)
                  3: Scheduled change -- (we want to waste as much time, resources, and money possible prior to any change being made)

                  Kpatch fits nicely into number 1 and 2. Rebooting a new kernel is not a quick option as you would literally have to restart ~1000 servers, which means there's 1000 opportunities for something to go wrong. Perhaps an NFS mount fails, perhaps a disk is full that didn't have an alert set, perhaps the bosons and errors invade.

                  Comment


                  • #10
                    Rh ftw!

                    Anything you can do... I can better...

                    and anything you can do sucks because we (effectively) own the kernel!!

                    RH FTW!

                    Comment


                    • #11
                      For those bringing Ksplice into this discussion... Keep in mind that Oracle now owns Ksplice and its future has been in flux and doubt ever since it was bought. My guess is that the buying of Ksplice is what started Suse and RedHat on writing a new solution (read the article: RedHat's been working on Kpatch for months)

                      Comment


                      • #12
                        Originally posted by Sonadow View Post
                        Ksplice, Kgraft and now Kpatch.

                        NIH syndrome at its best. And i'll bet that Kpatch eventually gets upstreamed just because it's from Red Hat.
                        kGraft was publicly announced on 2014-01-31: https://www.suse.com/communities/con...rnel-patching/

                        The announcement for Kpatch states that "the kernel team here at Red Hat has been working on a dynamic kernel patching project called kpatch for several months."

                        So, sounds like it was just a timing thing: both teams happened to work on the same thing at the same time. I don't know anything the public doesn't about Kpatch, but RH and SUSE devs have a long history of working together upstream, esp. on the kernel, so I'd be surprised if that doesn't happen here.

                        edit: looks like http://www.pro-linux.de/news/1/20758...it-kpatch.html may be vaguely interesting - anyone who can read German want to translate?

                        Comment


                        • #13
                          I'd prefer if KGraft came out ahead, just to give a few points to SUSE. Red Hat have enough.

                          Comment


                          • #14
                            Originally posted by xeekei View Post
                            I'd prefer if KGraft came out ahead, just to give a few points to SUSE. Red Hat have enough.
                            I'd prefer neither of them to end up in kernel but SuSE and RH engineers to sit in the same room, think of the good sides and bad sides of both implementations and implement a third one together that would be an evolutionary step from both.

                            Comment


                            • #15
                              Originally posted by AdamW View Post
                              kGraft was publicly announced on 2014-01-31: https://www.suse.com/communities/con...rnel-patching/

                              The announcement for Kpatch states that "the kernel team here at Red Hat has been working on a dynamic kernel patching project called kpatch for several months."

                              So, sounds like it was just a timing thing: both teams happened to work on the same thing at the same time. I don't know anything the public doesn't about Kpatch, but RH and SUSE devs have a long history of working together upstream, esp. on the kernel, so I'd be surprised if that doesn't happen here.

                              edit: looks like http://www.pro-linux.de/news/1/20758...it-kpatch.html may be vaguely interesting - anyone who can read German want to translate?
                              I'll give it a try:

                              Red Hat's Kpatch joins Kspilce and Kgraft

                              A week after Suse announced that they work on Kgraft, a framework for live patching of the kernel, Red Hat explained that they want to present their own software, named Kpatch at the end of march at the Collaboration Summit. This was unveilled by a Red Hat developer named Linda Wang in a lightning talk at devconf.cz.

                              Beneath Ksplice and OpenSuses Kgraft, this is the third technology in development for patching at the kernel runtime and without reboots. Ksplice has been in development since 2008, but was bought by Oracle in 2011 and hasn't been available under a free license since. Aditionally Ksplice wasn't upstreamed.

                              Suse and Red Hat still seem to be in early developement with those technologies, but it's unclear why both distributions are working on similar things at the same time instead of sharing the work. Concerning integration into mainline, it seems unlikely that two interfaces will be accepted.

                              The last paragraph is about why such a technology is needed anyways and not about the differences or anything like that, plus it links to a english website.

                              Comment

                              Working...
                              X