Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: Red Hat Intros Kpatch For Dynamic Kernel Patching

  1. #1
    Join Date
    Jan 2007
    Posts
    15,126

    Default 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. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,187

    Default

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

  3. #3
    Join Date
    Jul 2012
    Posts
    799

    Default

    Why do we need 3 of them?

  4. #4
    Join Date
    Jun 2009
    Posts
    563

    Default

    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.

  5. #5
    Join Date
    Nov 2010
    Posts
    78

    Default

    Quote 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.

  6. #6
    Join Date
    Jun 2006
    Location
    Portugal
    Posts
    536

    Default

    Quote 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!

  7. #7
    Join Date
    Jul 2013
    Posts
    7

    Default

    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.

  8. #8
    Join Date
    Sep 2012
    Posts
    750

    Default

    Quote 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?

  9. #9
    Join Date
    Jan 2009
    Posts
    466

    Default

    Quote 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.

  10. #10
    Join Date
    Nov 2007
    Posts
    53

    Default Rh ftw!

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

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

    RH FTW!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •