Red Hat Intros Kpatch For Dynamic Kernel Patching

[cjcox]

Rh ftw!

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

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

RH FTW!

[russofris]

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.

[erendorn]

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?

[[Knuckles]]

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!

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.

[Sonadow]

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.

[blackout23]

Why do we need 3 of them?

[curaga]

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

[phoronix]

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