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).
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the first organization which
gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.
Are you GAY ?
Are you a NIGGER ?
Are you a GAY NIGGER ?
If you answered "Yes" to any of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America. You, too, can be a part of GNAA if you join today!
Why not? It's quick and easy - only 3 simple steps!
First, you have to obtain a copy of GAY NIGGERS FROM OUTER SPACE THE MOVIE and watch it.
You can watch GAY NIGGERS FROM OUTER SPACE on Youtube.
Second, you need to succeed in posting a GNAA "first post" on slashdot.org , a popular "news for trolls" website
Third, you need to join the official GNAA irc channel #GNAA on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!
If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.easynews.com as one of the EFNet servers.
If you do not have an IRC client handy, you are free to use the GNAA Java IRC client by clicking here.
If you have mod points and would like to support GNAA, please moderate this post up.
This post brought to you by Penisbird , a proud member of the GNAA
G_____________________________________naann_______ ________G
N_____________________________nnnaa__nanaaa_______ ________A
A____________________aanana__nannaa_nna_an________ ________Y
A_____________annna_nnnnnan_aan_aa__na__aa________ ________*
G____________nnaana_nnn__nn_aa__nn__na_anaann_MERI CA______N
N___________ana__nn_an___an_aa_anaaannnanaa_______ ________I
A___________aa__ana_nn___nn_nnnnaa___ana__________ ________G
A__________nna__an__na___nn__nnn___SSOCIATION_of__ ________G
G__________ana_naa__an___nnn______________________ ________E
N__________ananan___nn___aan_IGGER________________ ________R
A__________nnna____naa____________________________ ________S
A________nnaa_____anan____________________________ ________*
G________anaannana________________________________ ________A
N________ananaannn_AY_____________________________ ________S
A________ana____nn_________IRC-EFNET-#GNAA________ ________S
A_______nn_____na_________________________________ ________O
*_______aaaan_____________________________________ ________C
Gary Niger gary_niger@gnaa.us GNAA Corporate Headquarters 143 Rolloffle Avenue Tarzana, California 91356
Enid Al-Punjabi enid_al_punjabi@gnaa.us GNAA World Headquarters No.33 Kyutei Bld. 2F, Shinjuku 2-11-7, Shinjuku-ku, Tokyo, Japan ????????2??11-6
Copyright (c) 2003-2015 Gay Nigger Association of America
Ich Bindawalross (London) - GNAA (NYSE: GNAA) President Nigger released a s
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.
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>
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 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!
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.
An ocean of new opportunities for rooted machines...
CLI paste? paste.pr0.tips!
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/
My balls hurt. Someone caress Tom Cruise's nipples immediately!
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.