Slashdot Mirror
Live Patching Now Available For Linux
New submitter cyranix writes "You may never have to reboot your Linux machine ever again, even for kernel patching," and excerpts from the long (and nicely human-readable) description of newly merged kernel code that does what Ksplice has for quite a while (namely, offer live updating for Linux systems, no downtime required), but without Oracle's control.
It provides a basic infrastructure for function "live patching" (i.e. code
redirection), including API for kernel modules containing the actual
patches, and API/ABI for userspace to be able to operate on the patches
(look up what patches are applied, enable/disable them, etc). It's
relatively simple and minimalistic, as it's making use of existing kernel
infrastructure (namely ftrace) as much as possible. It's also
self-contained, in a sense that it doesn't hook itself in any other kernel
subsystem (it doesn't even touch any other code). It's now implemented for
x86 only as a reference architecture, but support for powerpc, s390 and
arm is already in the works (adding arch-specific support basically boils
down to teaching ftrace about regs-saving).
This, among other things was discussed in the Kernel Report, at the recent Linux Conf in Auckland, New Zealand:
https://www.youtube.com/watch?...
Which means you can keep it up forever!
(PHRASING!)
Get free satoshi (Bitcoin) and Dogecoins
Yup. Exactly.
But then I guess the quest for epic uptime is bogus, right? Who the heck would want their system running 24/7 all the time?
*waits for Systemd flamewar to break out*
... to a more extreme version:
"I don't always test my code, but when I do it's via live patching the kernel on production"
Is this the anti-systemd?
Is this the anti-systemd?
<GANDALF>It IS systemd.
Or rather, systemd as it should have been.</GANDALF>
I can't possibly see this ever causing a problem with this because linux is very secure and there is absolutely no way for a malicious user to get elevated access on anything that runs linux. This includes android phones, which are totally invulnerable to hacking.
You should suggest to Linus that he make kernel features configurable so people can do different builds for different targets. Put it in a dot-config file or something. Maybe in a future release...
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I love recompiling kernels and updating config files whenever I buy a new mouse. It's the best system ever, and a great way to never open up security holes because all of those options are really well defined.
Truly, this is the year of linux on the desk top.
Maybe I’m old school, but this sort of bothers me. One of the nice things about rebooting is that it clears out old crud and gives you a reassurance that the system can bring itself up by its bootstraps. I can imagine live patching giving rise to a scenario where you have a machine that hasn’t been rebooted for years and when a power glitch finally brings it down, you find that what is on disk is different than what was in RAM and your kernel is corrupt or not bootable.
I think live patching would make sense if we had non-volatile system RAM (i.e. universal memory), but until then, it seems like rebooting is a pretty good sanity check that things are alright.
i'm kinda partial to seeing the errors so that i can fix them...*shrugs*...
There are three kinds of people in the world. Those that can count, and those that can't.
AIX had this in 1990s.
I love recompiling kernels and updating config files whenever I buy a new mouse.
Stop building your own proprietary PCIe mouse cards, knucklehead. You can buy a decent USB mouse for $12 now.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
But I'm a professional Starcraft player. The lag of USB packet overhead is killing me!
I think mainframes had this long before the '90s.
From the 1970s, Tandem Computers (now part of HP) specialized in high-availability computing. I'm pretty sure they've had the ability to patch their equivalent of a kernel for ages.
1980s-era electronic/digital telephone switches (the kind at telco switching offices, NOT your run-of-the-mill PBX) had uptimes measured in DECADES. I don't know if these switches had "live 'kernel' update" capability or not but they did have an "half and half" mode with "live fail-over" capability. One way of doing updates was to shut down one "half" gracefully, update it, bring it back up, leave it running for awhile, then repeat with the other "half". From a customer perspective, the switch was never "down".
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
This is awesome. Now that live patching is part of the kernel I expect it to be implemented in systemd very soon and all my GNU/systemd servers will never need a three finger salute again!
You should switch to Zerg so that you can A-move your roaches.
The OSes that ran on 8086-era computers and on very early Macs, as well as most consumer 8-bit OSes could in principle be patched or even completely overwritten without a reboot.
I vaguely remember an early Mac implementation of Lisp which basically "took over" the machine and gave you a command-line environment (look Ma! No menus!). You "ran" it by running a standard Mac application which basically took over the machine.
I seem to remember some DOS (if you can call that an OS) programs that worked basically the same way: They loaded themselves into memory, kicked the OS out, then when they quit, they asked you to insert a DOS disk and re-loaded DOS from disk without doing a hardware/BIOS-level reboot (or they knew how to read the hard disk boot tracks and loaded it from there).
With the advent of chips that provided real privilege levels and OSes that actually took advantage of them, such "takeovers" without the cooperation of the already-loaded OS became impossible by design (but still possible using exploits of course).
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I know TFS mentions ksplice, but I thought this was the purpose of kexec as well? So really, it's not anything new.
Buck Feta. You know what to do.
You didn't upgrade systemd. You upgraded the systemd package. You won't actually start using the new version of systemd until you do a reboot. And you ought to pray while you do that, even if you aren't religious. Based on my experience with systemd, there is a very good chance that your system will not boot properly, likely due to systemd failing in one or more obscure ways.
Ksplice and it's derivatives won't help you if you need to purge bad glibc code from memory, as we did for the recent "ghost" vulnerability.
That's how BootX (one of the Mac OS 8/9 Linux boot loaders for PowerPC Macs) worked. Mac OS would start loading, then a dialog would come up and you could select Mac OS or Linux. You could also run the application from Mac OS anytime after the OS was fully booted. In either case, when you selected Linux, it pushed Mac OS out of memory and Linux would start up.
End of Line.
.... what could possibly go wrong?
Although KSplice is nice (and functionality like this has been in Solaris/AIX/... for a really long time), last time I looked at it, it didn't support live-patching everything. You couldn't just bump an entire kernel version (as is possible on Solaris), only patch modules with a very specific patch as long as there are no processes using any part of it.
Custom electronics and digital signage for your business: www.evcircuits.com
I find it odd that the Linux kernel is able to support this, but major distributions (Fedora) are making userspace updates (like Firefox)[1] an "offline" process.
This seems like quite a reversal from a few years ago.
Maybe userspace updates will finally catch up to kernel updates and _not_ require downtime?
[1] http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
It was DOS itself doing that, but not a complete kick out : just command.com. If an application needed the memory, the DOS would reclaim that used by the command processor and reload it when the application finished.
You do know Windows supports live-patching of some parts of the code, right?
It isn't that dangerous when the alternative is running code that's known to be broken.
Not anymore it doesn't. Microsoft deprecated the hotpatch APIs in Win8. They were never used in production before that anyway. Maybe some special enterprise customers.
An ocean of new opportunities for rooted machines...
CLI paste? paste.pr0.tips!
And when it did most of it was in userspace - Heartbleed, ShellShock, GHOST ... to name a few recent ones. Restarting *everything* that depends on openssl or glibc is indeed possible without a reboot but really - reboot is just much easier.
kSplice and LivePatch do nothing for live userspace patching - overhyped solutions to something that isn't really a big problem.
The only thing remotely "new" about this is that Oracle is now running the show, I've used it on some of my Ubuntu servers since late 2009.
http://www.giantgeek.com/blog/
That sounds more like kexec, where the running kernel is replaced (which also means existing processes are all killed). This newfangled thing is for live patching, where everything (including userland) stays up.
The DOS part you are talking about works because it isn't doing multitasking; effectively, each app is the kernel as it runs. For later examples of this, any 386 or higher version of Windows (3.11 WFW, 95, ...) did basically the same thing.
you aren't fucking serious are you? kernel level escalation of privileges occur at a pretty steady rate throughout the year. If you can leverage a remote exploit into user space you will almost certainly be able to elevate your privileges from that point in all but the most seriously locked down systems.
@rgbe: "This, among other things was discussed in the Kernel Report, at the recent Linux Conf in Auckland, New Zealand:
How was this covered on slashdot, did I miss it?
Have to admit, it leaves a good anchor for someone to Hijack the thread and get a high position post to make their opinions on a matter known without having to go through the effort of getting an actual first post.
it actually updates systemd in ram by doing a reexec
Something which was possible for other processes.
To do this with the PID1 is something new.
And if that is going to work all the time is a mystery.
You could expect kernel panic on a systemd update.
Atari rules... ermm... ruled.