Linux 4.0 Getting No-Reboot Patching

An anonymous reader writes: ZDNet reports that the latest changes to the Linux kernel include the ability to apply patches without requiring a reboot. From the article: "Red Hat and SUSE both started working on their own purely open-source means of giving Linux the ability to keep running even while critical patches were being installed. Red Hat's program was named kpatch, while SUSE' is named kGraft. ... At the Linux Plumbers Conference in October 2014, the two groups got together and started work on a way to patch Linux without rebooting that combines the best of both programs. Essentially, what they ended up doing was putting both kpatch and kGraft in the 4.0 Linux kernel." Note: "Simply having the code in there is just the start. Your Linux distribution will have to support it with patches that can make use of it."

Comments

scientific computing

[e**(i pi)-1]

will be important for scientific computing. One of the weak points of OSX is the necessity to reboot even for minor stuff (but its also getting better there. Most upgrades in linux already do not require any reboot which is nice when having jobs running for weeks.

What could possibly go wrong?

[gb7djk]

Is it just me that is rather uncomfortable about the ability to do seamless, run time, patching on (any) operating system? Isn't there a rather large elephant of a precedent out there somewhere for the sorts of things that this facility this feature could be misused for?

Re:What could possibly go wrong?

[swillden]

It's no more a risk than current patching that requires a reboot, except that you don't have the downtime of a reboot.

Sure, if your concern is error, rather than malice. An attacker who gains root could use this to dynamically patch a backdoor into the running kernel. Rebooting the machine would potentially enable someone to notice.

As another poster noted, though, you can already dynamically patch the kernel for malicious purposes by loading a malicious module, assuming that hasn't been disabled. In contexts where security is crucial, I would disable both dynamic module loading and run-time patching.

Re:Finally...

[Bacon Bits]

Oracle bought it. Still surprised?

Not only that, but Oracle bought it on July 21, 2011. The current version of Ksplice? Released on July 28, 2011. The major feature of the current release? The changelog says the only change was "Removed unnecessary zlib detection from configure." But now only Oracle Linux is supported.

It's still available through source code, which you can find with a bit of digging (you can't navigate to it from the top level page, as far as I can tell... Ksplice isn't listed as a project). I think the amount of investment and effort put in that site makes it clear what Oracle's stance is.

At least Microsoft extends before they extinguish....

Re:Starting to feel old

[Gumbercules!!]

Coz all my servers are production or purpose defined, and based on CentOS or VyOS. They all work. They all do their jobs - so I haven't had a compelling reason to upgrade. I did put one server briefly on CentOS 7.0 (Kernel 3.10 or something) and the client couldn't figure out how to use it, so I rolled it back.

Re:Chicken, meet egg

[Anonymous Coward]

"Simply having the code in there is just the start. Your Linux distribution will have to support it with patches that can make use of it."

Darn. It looks like I'm gonna have to patch and reboot so I won't have to reboot after I patch.

FTFS: Essentially, what they ended up doing was putting both kpatch and kGraft in the 4.0 Linux kernel.

In other words the RedHat and OpenSuse teams decided no compromise is the best compromise. GNU/Linux used to stand on principles, now it is all about corporate control and marketing.