Replacing parts of the OS kernel without requiring a reboot is a neat trick. First there was kexec, next came Ksplice, which Oracle bought in 2011 and pretty much turned into Oracle-only payware. kGraft (SuSE) and kpatch (RedHat) were released in February 2014.
Now, Phoronix reports:
The newest kernel live patching solution uses an ftrace-based mechanism and kernel interface for doing live patching of the kernel with kernel module functions. According to Seth Jennings who posted the patches, "it represents the greatest common functionality set between kpatch and kGraft." Seth Jennings is a Red Hat developer. This new kernel live patching can accept kernel patches built by both kGraft and Kpatch. This design came out of the live patching mini-conference at the Linux Plumbers' Conference last month.
This new approach is just over one thousand lines of code in the kernel.
Related Stories
El Reg has noted:
Torvalds looses neatened number [release featuring] non-disruptive patches, Z13 support, and more.
[...] The new number isn't a sign of a major upgrade. As we've chronicled, Torvalds thinks that it looks a bit silly when version numbers go beyond x.19.
As the Benevolent Dictator for Life says in his post at the kernel mailing list:
since rc7 [...] It's mainly driver fixes (media, sound, pci, scsi target, drm, thermal..), misc arch updates (nios2 and x86), and scattered fixes elsewhere. Really not a lot during the last week.
After you folks hammered on the 7 release candidates and gave the kernel team bug reports, any drama seems to have been wrung out.
We previously discussed the never-need-to-reboot patching feature that has now been incorporated into the kernel.
Josh Boyer of the Fedora Project reports
[In Linux kernel 4.0], there is one feature that people (and various media sites) seem to have keyed in on and that is the live patching functionality. This holds the promise of being able to patch your running kernel without rebooting. Indeed, this could be very useful, but it isn't quite there yet. And it also doesn't make a whole lot of sense for Fedora at this time. The Fedora kernels have this functionality disabled, both in Fedora 22 and Rawhide.
What was merged for 4.0 is the core functionality that is shared between two live patching projects, kPatch and kGraft. kPatch is being led by a development team in Red Hat whereas kGraft is being developed by a team from SuSE. They both accomplish the same end result, but they do so via a different approach internally. The two teams met at the Linux Plumbers conference last year and worked on some common ground to make it easier to merge into mainline rather than compete with each other. This is absolutely awesome and an example of how new features should be developed upstream. Kudos to all those involved on that front.
The in-kernel code can accept patches from both methods, but the process and tools to create those patches are still being worked on in their upstream communities. Neither set are in Fedora itself, and likely won't be for some time as it is still fairly early in the life of these projects. After discussing this a bit with the live patching maintainer, we decided to keep this disabled in the Fedora kernels for now. The kernel-playground COPR does have it enabled for those that want to dig in and generate their own patches and are willing to break things and support themselves.
In reality, we might not ever really leverage the live patching functionality in Fedora itself.
(Score: 2) by cafebabe on Wednesday November 12 2014, @02:59AM
Thank you, RedHat, for making it easier for hostile parties.
I hope there's a method to compile without this functionality. Preferably, it should be the default option to compile without this functionality.
1702845791×2
(Score: 2) by The Mighty Buzzard on Wednesday November 12 2014, @12:29PM
Yeah, that was my first thought too. Then I remembered hacker types had been overwriting the bits of the kernel they wanted to replace the functionality of for decades now and we might as well have an easy way to do it legit-like too and save ourselves some reboots.
My rights don't end where your fear begins.
(Score: 4, Funny) by Anonymous Coward on Wednesday November 12 2014, @03:00AM
Why do Linux systems today even have a kernel? Couldn't everything just run on systemd, which could run on the hardware directly?
(Score: 2) by Marand on Wednesday November 12 2014, @06:58AM
Why do Linux systems today even have a kernel? Couldn't everything just run on systemd, which could run on the hardware directly?
That's why a RedHat employee implemented this kernel functionality. Soon systemd will use the patching mechanism to bootstrap systemd-kerneld. GNU/Linux is old stuff; all hail our new GNOME/systemd overlords! ;)
(Score: 2) by davester666 on Thursday November 13 2014, @06:49AM
The kernel is just used to get emacs launched, which takes over controlling all the hardware.
(Score: 2) by Arik on Wednesday November 12 2014, @03:07AM
At least it's only a thousand lines, shouldnt be too hard to edit it out before compiling.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Wednesday November 12 2014, @03:17AM
Because you can do that already? Unless something has changed drastically in the kernel memory model, any module can overwrite anything anywhere. So what is your gripe with patching without rebooting? I already do something similar when I update nvidia driver.
1. update nvidia driver, install it
2. shut down X
3. remove old one with `modprobe -r nvidia`
4. install new one with `modprobe nvidia`
5. `startx`
Much better than restarting. Saves quite a bit of time filling all that file system cache.
(Score: 4, Interesting) by novak on Wednesday November 12 2014, @03:24AM
Kernel live patching, also known as rootkit_builder.
I guess it might be useful in systems that are pretty well isolated but have ridiculous uptime requirements.
novak
(Score: 3, Insightful) by DECbot on Wednesday November 12 2014, @03:57AM
I'd rather not have to reboot my server while the NSA is performing updates to my machine. Now with systemd and live kernal patching, I will never even know they were there.
cats~$ sudo chown -R us /home/base
(Score: 0) by Anonymous Coward on Wednesday November 12 2014, @04:00AM
What can you tell me about Digital UNIX and OSF/1?
(Score: 0) by Anonymous Coward on Wednesday November 12 2014, @04:58AM
"I'd rather not have to reboot my server while the NSA is performing updates to my machine. Now with systemd and live kernal patching, I will never even know they were there."
I think Lennart Poettering said it best when he said: "The future is going to be awesome!"
(Score: 2, Informative) by stroucki on Wednesday November 12 2014, @05:40AM
They could already just "insmod backdoor.ko" without rebooting.
(Score: 3, Interesting) by Marand on Wednesday November 12 2014, @07:06AM
Now with systemd and live kernal patching, I will never even know they were there.
That brings up an interesting question. One of systemd's most often touted benefits is faster boot time, but if you can live-update the kernel, why even bother with systemd at all? Better to have an ultra-tiny init that does as little as possible and never needs patching so that everything else on the system can be swapped out at will.
(Score: 1) by monster on Wednesday November 12 2014, @03:22PM
Now you are thinking logically. Why do you have to be so mean to that Lennart guy?
(Score: 0) by Anonymous Coward on Wednesday November 12 2014, @11:01PM
systemd supports reboot-less upgrades [freedesktop.org], so there isn't really an advantage over a simple init. Besides, a) systemd's main goal is not "faster boot" (its main goal is to be a full-blown daemon manager) and b) live patching is meant for machines that should have ridiculously high availability, not for general use. Kpslice (and probably the others, but YMMV) has performance degradation on every call to a patched function
(Score: 1) by stroucki on Wednesday November 12 2014, @05:46AM
I set up a cluster management system with hundreds of nodes where machines netbooted into a common management environment, did whatever stuff I wanted it to, and then kexec'ed into the OS installed on the local disk, without going through the BIOS or grub drag.
What would be nice is to have the ability to block these interfaces, including module loading, if certain conditions aren't given. Sort of like a write-protect BIOS jumper for the kernel.
(Score: 0) by Anonymous Coward on Wednesday November 12 2014, @07:16AM
Seriously though, I kinda get where all the security-related worry posts are coming from, but realistically we can assume that you need root to live patch a kernel under any circumstances (unless it's been rigged by the admin for ease of use or to be compatible with some server management package*), right? If the attacker has root it's game over anyway, what's all the fuss?
*in that case the admin should either know what they're doing or get what they deserve.
(Score: 3, Interesting) by DECbot on Wednesday November 12 2014, @05:49PM
kinda get where all the security-related worry posts are coming from, but realistically we can assume that you need root to live patch a kernel under any circumstances (unless it's been rigged by the admin for ease of use or to be compatible with some server management package*), right?
That's why systemd has systemd-logind, so you don't need root, and systemd-journald, so all events are "written" into the log. So, hold on... let me get my tin foil hat so I won't be overheard by snoops. Using systemd-networkd, the computer is directed to use an NSA 'approved' DNS server, and then, using a cache poisoning bug in systemd-resolved, NSA points the machine to a NSA controlled server to inject specially crafted packets to cause systemd launch the required services to gain access to the machine. From there, it gets root through logind, and live patches the kernel without journald recording it. And if journald does happen to record it, well, that's why the log is binary, corrupt it and GTFO.
I'm probably going to have to get wire mesh from the hardware store soon so I can make proper faraday cage headware. My tin foil is quickly wearing out.
cats~$ sudo chown -R us /home/base
(Score: 2) by meisterister on Thursday November 13 2014, @01:13AM
Nosiree! The SystemD stack is by no means a massive security hole. Nope. The NSA even said so themselves!
(May or may not have been) Posted from my K6-2, Athlon XP, or Pentium I/II/III.
(Score: 0) by Anonymous Coward on Wednesday November 12 2014, @12:05PM
I have been tying knsa to patch the kernel.
Been working great, however, my internet connection seems to have far more traffic than before.
(Score: 3, Informative) by opinionated_science on Wednesday November 12 2014, @04:51PM
for those who think this is a new attack vector, that was loadable modules...
And a few more customers of Oracle can jump ship...
(Score: 2) by mtrycz on Wednesday November 12 2014, @05:39PM
So the company that already has a paid product, makes an open sourced piece of software that lets you patch the most critical part of your system online and that is actually better than their paid alternative?
I just cannot state enough the level of my excitement about all of this.
In capitalist America, ads view YOU!
(Score: 1) by KiloByte on Thursday November 13 2014, @02:54AM
So what's the point of live-patching the kernel if systemd tries hard to force two reboots just to update any package?
Ceterum censeo systemd esse delendam.