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?
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)
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.
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
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.
No, that's completely wrong. The new version will run if the package upgrade script tells the daemon to re-exec itself. Which (at least in the case of RHEL7), it does.
Need to type accents and special characters in Windows? Use FrKeys
An ocean of new opportunities for rooted machines...
CLI paste? paste.pr0.tips!
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.
@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?
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.