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

Starting to feel old

[Gumbercules!!]

I'm starting to feel old. I'm still on 2.6.x on my boxes.

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:Starting to feel old

[NatasRevol]

Only people without servers in production/critical environments ask 'why haven't you upgraded already?'

Re:Starting to feel old

[haruchai]

And that's how my team ended up supporting 10 - 25 yr old fossilized gear running all kinds of old, insecure shit that almost noone can remember what's the login or sometimes what's it for.

Re:Systemd in 4.0-era, for or against?

[Ol Olsoc]

Isn't there a Women in STEM or global warming thread for you to infest?

Chicken, meet egg

[Marginal 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.

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.

Re:scientific computing

[chuckymonkey]

If you have weeks long running jobs on your desktop you're doing it wrong. There's a reason servers exist in datacenters. I work in scientific computing and people running jobs on their desktop is a huge problem, they spend ridiculous amounts of money for something like a Mac Prol to run this stuff on when they should be buying actual servers instead. Then complain when their desktop is running like shit or their job fails because the building took an intermittent power hit. You can even put GPU compute in servers and have a lot less concern for your systems going down.

Re:scientific computing

[MachineShedFred]

On OS X the reboot is for user convenience. If you use the command line software update tools, you can install them as you wish, and not reboot. Then you can restart services with launchctl or reload patched kexts and save yourself a reboot. Does this take a lot of extra time and testing? Sure - thus the reboot.

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?

[MachineShedFred]

It's been used for decades everywhere except the PC and it's server variants. It's no more a risk than current patching that requires a reboot, except that you don't have the downtime of a reboot.

A bad patch is a bad patch. Have backups, have redundancy.

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:What could possibly go wrong?

[swillden]

But what you're saying is that rebooting is somehow a magic cure-all that guarantees the system isn't infected somehow

Don't be condescending. I'm not saying rebooting is a magic anything.

Whether or not this matters depends on the threat model and why the attacker is interested in patching the kernel. For example, one purpose would be to disable other kernel security features, such as SELinux, or dm-verity. Most SELinux rules are configured and the configuration can be altered by root, but some are compiled into the kernel and can only be modified by modifying the kernel. Altering the persistent kernel image may not be possible for a variety of reasons (read-only media, SecureBoot, etc.). In addition, in security-sensitive and mission-critical contexts an unexpected reboot may well be noticed.

I don't understand your assertion about SecureBoot. Are you referring to some known vulnerability of some particular secure boot system? Given a decent implementation of secure/verified boot, an attacker should not be able to convince the system to boot a modified kernel image, which means that run-time modification of the kernel is the only option if the attacker needs to bypass some kernel security enforcement.

In general, the security model of a high-security Linux system assumes that the kernel is more trustworthy than root. The ability for root to modify the running kernel invalidates this assumption, which most definitely is a security issue.

In the context of a system without mandatory access controls there may not be any reason to care, since once an attacker has obtained root there probably isn't any limit to what he can do.

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