Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux 4.0 Getting No-Reboot Patching

Posted by Soulskill on from the post-your-uptimes dept.

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."

26 of 125 comments (clear)

  1. Starting to feel old by Gumbercules!! · · Score: 4, Insightful

    I'm starting to feel old. I'm still on 2.6.x on my boxes.

    1. Re:Starting to feel old by Gumbercules!! · · Score: 3, Interesting

      Coz all my servers are production or purpose defined, and based on CentOS or VyOS. They all work. They all do their jobs - so I haven't had a compelling reason to upgrade. I did put one server briefly on CentOS 7.0 (Kernel 3.10 or something) and the client couldn't figure out how to use it, so I rolled it back.

    2. Re:Starting to feel old by NatasRevol · · Score: 5, Insightful

      Only people without servers in production/critical environments ask 'why haven't you upgraded already?'

      --
      There are two types of people in the world: Those who crave closure
    3. Re:Starting to feel old by haruchai · · Score: 4, 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.

      --
      Pain is merely failure leaving the body
    4. Re:Starting to feel old by NatasRevol · · Score: 2

      There's a huge difference between 'why haven't you upgraded?' and 'why haven't you upgraded already?'.

      --
      There are two types of people in the world: Those who crave closure
    5. Re:Starting to feel old by dwywit · · Score: 2

      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.

      --
      They sentenced me to twenty years of boredom
  2. Re:Systemd in 4.0-era, for or against? by Ol+Olsoc · · Score: 4, Funny

    Isn't there a Women in STEM or global warming thread for you to infest?

    --
    The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
  3. Re:Systemd in 4.0-era, for or against? by sumdumass · · Score: 2

    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 something.

  4. Chicken, meet egg by Marginal+Coward · · 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.

    1. Re:Chicken, meet egg by wonkey_monkey · · Score: 2

      Yo dawg, I heard you

      Ah, screw it.

      --
      systemd is Roko's Basilisk.
    2. Re:Chicken, meet egg by Anonymous Coward · · 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.

  5. scientific computing by e**(i+pi)-1 · · Score: 4, Interesting

    will be important for scientific computing. One of the weak points of OSX is the necessity to reboot even for minor stuff (but its also getting better there. Most upgrades in linux already do not require any reboot which is nice when having jobs running for weeks.

    1. Re:scientific computing by chuckymonkey · · Score: 4, Insightful

      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. Then complain when their desktop is running like shit or their job fails because the building took an intermittent power hit. You can even put GPU compute in servers and have a lot less concern for your systems going down.

      --
      "Some books contain the machinery required to create and sustain universes."-Tycho
    2. Re:scientific computing by MachineShedFred · · Score: 3, 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.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    3. Re:scientific computing by serviscope_minor · · Score: 2

      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 of 5 of compute days wasted per year due to power outages. And that's assuming the job doesn't checkpoint itself to allow for continuation (mine did).

      That was an excessive case. Even so, a few-day job or an overnighter or so on is completely fine, but you'd still find reboots annoying.

      Then complain when their desktop is running like shit

      I've never had a problem with that on Linux. Even if you load up the CPU with one full job per core, the system stays very responsive. Hell even with one job per hyper-thread on Intel, which is overloaded by a factor of nearly 2 and it's pretty responsive, especially if you renice the jobs.

      You have to go waayyy over the capacity of the machine to make it run like crap.

      You can even put GPU compute in servers and have a lot less concern for your systems going down.

      True, but there are fewer options for those and they're often much more expensive and less good in servers compared to desktops, depending on the workload.

      --
      SJW n. One who posts facts.
    4. Re:scientific computing by bored · · Score: 2

      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 machine running in the server room with a much better power and cooling environment.

      That said, it is possible to get something like the Xeon E5-2637 v3 which is a quad core, 3.5 Ghz (+turbo) CPU. Sure its not the the 4+Ghz you can get on a "desktop" CPU but it does have a LGA 2011v3 which will give you significantly more memory bandwidth and ECC.

      Frankly, while I think running anything besides a desktop workload on a "desktop" is silly because those kinds of workloads tend to be better handed with servers. It does seem that intel has lost its way a little when it comes to extreme single threaded performance. Particularly in the server space. Why they don't offer a 200+ watt pig clocked a few percent higher seems strange. Pretty much everyone else does it (POWER8, z13 (@ 5.2 Ghz), AMD, etc).

  6. What could possibly go wrong? by gb7djk · · Score: 3, Interesting

    Is it just me that is rather uncomfortable about the ability to do seamless, run time, patching on (any) operating system? Isn't there a rather large elephant of a precedent out there somewhere for the sorts of things that this facility this feature could be misused for?

    1. Re:What could possibly go wrong? by MachineShedFred · · 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.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    2. Re:What could possibly go wrong? by gb7djk · · Score: 2

      Yes, it's been around in server environments for years. Whilst one can see a case for adding this facility to linux servers in properly wrangled environments, my concern is on yer actual PCs, such as the one I am typing this on at the moment.

    3. Re:What could possibly go wrong? by swillden · · Score: 3, 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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:What could possibly go wrong? by swillden · · Score: 3, 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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  7. Re:Finally... by Bacon+Bits · · 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, 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....

    --
    The road to tyranny has always been paved with claims of necessity.
  8. You're kidding, right? by SIGBUS · · Score: 2

    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

    --
    Oh, no! You have walked into the slavering fangs of a lurking grue!
  9. Re:So basically we're finally catching up to Novel by Lumpy · · Score: 2

    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.

    --
    Do not look at laser with remaining good eye.
  10. Re:Systemd in 4.0-era, for or against? by serviscope_minor · · 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.

    --
    SJW n. One who posts facts.
  11. Re: Systemd in 4.0-era, for or against? by sumdumass · · Score: 2

    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.