Linux 4.0 Getting No-Reboot Patching 125
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."
Starting to feel old (Score:5, Insightful)
Re: (Score:2)
Just curious, why?
Re:Starting to feel old (Score:4, Interesting)
Re:Starting to feel old (Score:5, Insightful)
Only people without servers in production/critical environments ask 'why haven't you upgraded already?'
Re:Starting to feel old (Score:5, Insightful)
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: (Score:1)
No, your workplaces complete lack of enforcing a documentation policy is why you have that mess. You're job isn't to run shiny new OS installs, your job is to keep everything running smoothly. Good documentation is a part of that.
Re: (Score:3)
There's a huge difference between 'why haven't you upgraded?' and 'why haven't you upgraded already?'.
Re: (Score:2)
Perhaps.
But depending on the system or product, that difference may not be large.
One vendor allowed us to run fully supported on a particular product version for 5+ yrs but now requires us to upgrade again, after only 2 years, by the end of 2015.
Upgrading this system affects about 5000 users & 35 external partners and required almost 4 months of preparation & co-ordination.
Re: (Score:3)
And that's why my hourly rate goes up, up, and away when the client can't supply documentation. It doesn't decrease the frustration, but helps to make it bearable.
Not going to get any better (Score:1)
If you were lost in the 3.0 kernels just wait until you try 4.0. Gone are the days of simply using ifconfig or adding a shell script to run on startup. Move to some form of BSD where the development process is sane. Changing for the sake of change is not a good idea.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
$ uname -a
Linux snail 2.4.37.11 #2 Tue Dec 28 14:55:32 PST 2010 i586 Pentium MMX GenuineIntel GNU/Linux
Re: Starting to feel old (Score:1)
He's on CentOS; they have this absurd scheme for kernels where they freeze the reported version and apply "selected patches" for 5+ years, so you never know what bugs are fixed.
You're kidding, right? (Score:3)
He's on CentOS; they have this absurd scheme for kernels where they freeze the reported version and apply "selected patches" for 5+ years, so you never know what bugs are fixed.
You can get the kernel changelog easily enough:
rpm --changelog kernel
oops (Score:2)
Make that: rpm -q --changelog kernel
Re: You're kidding, right? (Score:2)
Yes, but vulnerabilities are generally described as "introduced in x" or "fixed in y". Range checking a version is much easier than searching a change log.
Re: (Score:2)
Senile and demented people typically think the problem is with others...
Finally... (Score:1)
Re: (Score:2)
The kernel parts have always been free under GPL2.
The part of this that is worth money is creating patches to apply with this system. Patches that won't crash the machine or corrupt data.
Re:Finally... (Score:5, Interesting)
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 [oracle.com], 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....
Now it sounds like 4.x (Score:2)
Re: (Score:2)
Wasn't this posted a week or two ago?
Yep, it was discussed in Linux Kernel Switching To Linux v4.0, Coming With Many New Addons [slashdot.org]
Chicken, meet egg (Score:5, Funny)
"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.
Re: (Score:3)
Yo dawg, I heard you
Ah, screw it.
Re: (Score:2)
Re: (Score:1)
Yo Dawg! We heard you liked to patch. So we got you a patch to patch your patches while you're patching.
And gamification will be forthcoming so you can earn badges and stickers if you successfully complete each rebootless patch patch patch. Damn hipsters!
Mr. Torvalds please return Linux to its principled roots and forbid corporate control.
Re: (Score:2)
And gamification will be forthcoming so you can earn badges and stickers if you successfully complete each rebootless patch patch patch. Damn hipsters!
Mr. Torvalds please return Linux to its principled roots and forbid corporate control.
I like the pretty gold round ones! Yay- me for stickers!
Re: (Score:2)
Patches? We ain't got no patches. We don't need no patches. I don't have to show you any stinking patches. [imdb.com]
Re: (Score:2)
Patches? We ain't got no patches. We don't need no patches. I don't have to show you any stinking patches. [imdb.com]
"He said, "Patches
I'm dependin' on you, son
I tried to do my best
It's up to you to do the rest"......"
We'll see how many get that reference....
Re: (Score:2, Interesting)
"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.
Re: (Score:2)
Without reboots, how am I to know if I setup my rc.d scripts correctly? Or kill that background app a user ran nohup myscript.sh &
I mean without having to reboot the system, I am expected to do real systems administration work, not just a blanket refresh everything, once in a while. Patches gave me a good excuse to do such.
Re: (Score:1)
scientific computing (Score:5, Interesting)
Re:scientific computing (Score:5, Insightful)
Re: (Score:3)
If you have weeks long running jobs on your desktop you're doing it wrong.
I disagree, speaking as someone who has in fact had a weeks long job running on my desktop before. I mean if you have a fast PC (desktop processors are often faster per core, at the expense of fewer cores) and it's a single threaded job (sadly, not all workloads are parallelisable) then it makes sense to run it locally.
If power outages happen once per year (I think that's pessimistic), and the job lasts a month then that's an average
Re: (Score:3)
I disagree, speaking as someone who has in fact had a weeks long job running on my desktop before. I mean if you have a fast PC (desktop processors are often faster per core, at the expense of fewer cores)
Well you have to differentiate whether your talking about an intel desktop machine or a "workstation" class machine. The difference at this point is the "workstation" is using xeon class processors, and has ECC. The problem is that the "workstation" has exactly the same processors as the rack mount machin
Re: (Score:2)
If you have a weeks-running job and it isn't fault-tolerant, you're doing it wrong, period. As long as it's fault-tolerant, it isn't a big deal where it's run.
That said, if you have a job that takes days to run on a single computer, it'd be a good idea to either invest in a compute cluster or get some time on one.
Re: (Score:2)
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.
I agree the Mac Pro is a bad choice (overpriced), but most servers are more expensive than a fast desktop with similar performance. Given that you need a desktop PC anyway, it often make sense to invest an extra $500 or even $1000 in it to save the costs of a server.
Re: (Score:2)
If you have weeks long running jobs on your desktop you're doing it wrong.
Some of us cannot afford our very own personal render farm [wikipedia.org], or justify the cost of renting time on one, merely to satisfy our little hobbies. ;)
Personally though, it's not just work that keeps us from rebooting. On my part, it's usually a month or two between reboots on my MBP laptop, and even then patching is usually the only reason... why bother waiting for a full boot process to finish when I don't have to? Close the lid and let it go to sleep... it's only a few seconds waiting for it to wake up when I w
Re: (Score:2)
If you have weeks long running jobs on your desktop you're doing it wrong. There's a reason servers exist in datacenters.
*SNIP*
when they should be buying actual servers instead.
*SNIP*
You can even put GPU compute in servers and have a lot less concern for your systems going down.
Well since you offered, could you make your paypal payment to me about $6000 USD for a mid-range server?
Or since you're being so generous offering to pay for servers for us, how about a nice even $10000 and I'll get one of those newfangled blade systems!
Re: (Score:2)
scientific computing. One of the weak points of OSX
I would have guessed that the high price per unit work for their proprietary hardware would be the limiting factor. Can't you hire for "free" a dedicated linux admin for the cost difference between clusters?
Or is there a specific advantage OSX is bringing to the table? XGrid is long dead, right?
Re: (Score:2)
scientific computing. One of the weak points of OSX
I would have guessed that the high price per unit work for their proprietary hardware would be the limiting factor.
Not really - you can still buy old XServe boxes for a relatively reasonable price, pack them with RAM, and load ESXi on each one so that you can run a buttload of little OSX VMs on each one. Yes, it's perfectly legit to do exactly that under the Apple EULA (I did it for a former employer who wanted rack-mounted OSX instances for testing - it was its own little cluster in a vSphere farm, and it was far easier to clone off replacements or new VMs.)
Re:scientific computing (Score:4, Informative)
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.
Re: (Score:2)
Yeah, it's also like, "In order for the update to full take effect and work correctly, we need to restart a bunch of services and applications. You should save all your work, since various things might close or stop working for a little bit." You can explain that to users, have them not pay attention, and then get pissed off because the update closed their document that they didn't save. Or you can just tell them that you're going to reboot.
Users understand rebooting better.
What could possibly go wrong? (Score:4, Interesting)
Re:What could possibly go wrong? (Score:5, Insightful)
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: (Score:3)
Re:What could possibly go wrong? (Score:4, Interesting)
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: (Score:2)
At all points you can modify the kernel, there's a potential for mischief, of course.
But what you're saying is that rebooting is somehow a magic cure-all that guarantees the system isn't infected somehow, or that there's a user (or SecureBoot) there to "notice" something amiss.
If SecureBoot can be fooled into loading an older kernel that can then be upgraded on-the-fly, it can be fooled into doing that at boot too.
How often do you check your machine boot-up process to ensure it's on the version that grub et
Re:What could possibly go wrong? (Score:4, Informative)
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: (Score:2)
If someone gains root, they can swap out the on-disk boot image that contains the kernel, and wait for someone else to reboot it as part of normal maintenance.
Assuming there isn't something that prevents the boot image from being replaced. See my other, more extensive, comment in this thread.
Re: (Score:2)
sorry AC, I've got no mod points for you, but you are exactly right, except in the good old days of NW 3.x , netware admins would laugh at someone bragging about 300 days of uptime. I worked with NW sites that had servers with years of uptime. I've had unix servers that had years of uptime, not that that was a smart thing. It just meant they were running on reliable HW and hadn't been patched for years. With NW you could have servers with years of uptime and up to date SW.
The last NW site I worked at (late
Re: (Score:3)
One place I worked at we had a horribly out of date NW server on the network that nobody knew where it was... I searched for weeks and could not find it. Finally years later it was found inside a wall because of previous construction it was placed out of the way and covered with a plastic tarp.
So it was running all those years WITH NO AIRFLOW and no reboots. A testament to old SCSI hard drives.
Re: (Score:2)
This...this is amazing!
Re: (Score:2)
sorry AC, I've got no mod points for you, but you are exactly right, except in the good old days of NW 3.x , netware admins would laugh at someone bragging about 300 days of uptime.
I've had over 200 days uptime on my Vista desktop system, and that was ended by a power cut. Uptime isn't really anything to brag about any more.
Re: (Score:2)
Such datacentre-level facilities often take decades to come down to consumer hardware and consumer OS.
Virtualisation is, to x86 PC's, relatively new. But we've been doing it on the proper hardware for decades.
It's not that some things were so brilliant, it's that the features are rarely needed and take a long time to filter down to commodity OS and hardware.
Hell, I've never needed a cluster-based filesystem, and you don't see me complaining that Windows didn't introduce one to Windows until decades after t
In a world... (Score:1, Funny)
In a world, where slashdot stories get repeated at least twice per week, one man had finally had enough.
Dilbert Smith was your average computer programmer, until one day, it happened, and the world would never be the same.
Jean Claude Van Damme is .... The UNDUPLICATOR.
Re: (Score:2)
To live-patch, you'd need to run code as root.
If a malicious executable ever gets root, it can persist itself in any fashion it likes. Live-patching isn't a necessity, nor a hole in this sense.
Even with SecureBoot, there's nothing stopping such code going through boot up again, and exploiting the same hole again through any of the millions of ways a root-running-executable could make something start at startup.
So long as this works in tandem with facilities like cryptographic module signatures, I don't see
Re: (Score:2)
Hear, hear! Let's throttle that shit back to the 386, and the hell with these new-fangled 32-bit processors!
Why both? (Score:2)
Ummm (Score:1)
We already had this with the modules... (Score:2)
Very cool that you can now patch and reload the core without a reboot, I just wonder how they handle when data structures change dramatically between major versions, will they replace the running data with predefined?
Re: (Score:2)
Don't quote me on it, but from my understanding of the trampoline kernel patches there's a point at which the calls to old system calls are blocked and the calls to the new replacement system calls are demanded.
There's a lot of logic involved in determining when the system is in a state to do that such that you don't end up feeding new structures to old syscalls, or old structures to new syscalls mid-way through (by checking that their dependent / source syscalls are all upgraded by that point, etc.)
But, mo
Great for servers, not that much for desktops (Score:2)
Application restart (Score:2)
We are heading to the situation where patching the kernel will be faster than patching applications:
Kernel upgrade: no downtime
Adjusting a parameter in Java application: wait for 4 minutes for Glassfish to restart
Excellent news... (Score:1)
Re:Systemd in 4.0-era, for or against? (Score:5, Funny)
Re: (Score:3)
Isn't there a Women in STEM or global warming thread for you to infest?
If systemd has any bearing on women in STEM or global warming, then truly its scope has become more vast than any dared to dream or dread.
Re: (Score:2)
Isn't there a Women in STEM or global warming thread for you to infest?
If systemd has any bearing on women in STEM or global warming, then truly its scope has become more vast than any dared to dream or dread.
Does seem to be trolls that try ot turn every topic into a referendum on systemd.
And those three topics generate a lot of activity.
Re: (Score:1)
Re: (Score:3)
Wow, not only is the story a dupe, so is the lame attenpt to hijack it and.make it about/ whine about systemd.
Now all we need is for aa bunch of dupes pointing this out and we can just take off for a mini vacation before we all fork the kernel and role our own and try to hijack every other linux story.
I do not know what to think about systemd other than it seens to work but i do know i'm about sick with the people trying to inject it inti any linux related story. Perhaps someone should just move to BSD or s
Re: (Score:3)
lol.. Just like sysV is an inherent discussion topic for anything related to linux? How about X11 or whatever it is now? Grep, and VI I guess should always be on topic too.
I think you have too much emotionally invested in something and and it's clouding your judgement.
Re: (Score:2)
Wow, I get the joke wasn't funny, but it's on topic, not off topic. An "overrated" mod would be more appropriate than an "off topic" one.
Re: (Score:1)
What's it like in your parallel world? I'm running an investment and billing platform, as well as the testing and development environments on ~60 Linux instances far more securely than if it was on Windows. We have 4 Windows servers in our platform for AD and because someone requires reporting in MS SQL, and they spend far more time patching and rebooting than the ~60 Linux instances do. That OS *is* profitable enough for someone to want to fix it, and yet it still hasn't been.
Go spread your FUD elsewher
Re: In a parallel world. (Score:1)