Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday October 26 2016, @08:48AM   Printer-friendly
from the no-reboots dept.

LWN (formerly Linux Weekly News) reports

Canonical has announced the availability of a live kernel patch service for the 16.04 LTS release. "It's the best way to ensure that machines are safe at the kernel level, while guaranteeing uptime, especially for container hosts where a single machine may be running thousands of different workloads."

Up to three systems can be patched for free; the service requires a fee thereafter. There is a long FAQ about the service in this blog post; it appears to be based on the mainline live-patching functionality with some Canonical add-ons.

Another distro, not wanting to be left out of the recent abundance of limelight has made some noise of its own.

Phoronix reports

KernelCare Is Another Alternative To Canonical's Ubuntu Live Kernel Patching

The folks from CloudLinux wrote in to remind us of their kernel patching solution, which they've been offering since 2014 and believe is a superior solution to Canonical's service. KernelCare isn't limited to just Ubuntu 16.04 but also works with Ubuntu 14.04 and other distributions such as CentOS/RHEL, Debian, and other enterprise Linux distributions.

Another big difference to Canonical's Livepatch is that KernelCare does support rollback functionality while Canonical doesn't appear to support it at this time. KernelCare can also handle custom patches, 32-bit support, and they share they plan [sic] to soon begin offering livepatching support for glibc, OpenSSL, and QEMU.

The downside though is that KernelCare appears to rely upon some binary blobs as part of its service. Pricing on KernelCare ranges from $25 to $45 USD per year depending upon the number of licenses being purchased.

[Details at] CloudLinux.com.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by Runaway1956 on Wednesday October 26 2016, @10:45AM

    by Runaway1956 (2926) Subscriber Badge on Wednesday October 26 2016, @10:45AM (#418917) Journal

    Just how literally should we take you? Should we assume that you write your own kernel, line by line, and that EVERYTHING is under your direct control?

    Computing is a world of compromises. All of us decide who to trust, and how much to trust them. All of us have been burned by misplaced trust. But, we trust SOMEONE, or we wouldn't be on computers at all. Those of us who are more paranoid tend to trust very few people, and we double check everything, compile our own binaries, and don't use any proprietary binary blobs. Those of us who are more gullible run Windows. The REAL paranoids don't trust anyone, and they are still fabbing their own CPU's, mainboards, GPU's, etc.

    Compromise. Get informed, decide who you trust, and stick with that decision until you have reason to change it.

    Personally, I "trust" nvidia for their binary blobs. It's not a blind trust, I know that nvidia has screwed the pooch a few times in it's history. But, still, I use their blobs. I don't trust Microsoft, but for some strange reason I'm "trusting" Oracle and VirtualBox. Compromise.

    It might be good if we could make some kind of scale we could guage ourselves on. I'm not totally paranoid, but I'm not the most gullible customer in the market either. On a scale of 1 to 10, with 10 being the most trusting of Microsoft sycophants, I hope that I'm closer to 2, 3, or 4 than to 10. Maybe you need to be at zero, for some reason.

    Starting Score:    1  point
    Moderation   +3  
       Insightful=3, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 1, Interesting) by Anonymous Coward on Wednesday October 26 2016, @11:13AM

    by Anonymous Coward on Wednesday October 26 2016, @11:13AM (#418926)

    as a fellow paranoiac i can understand what he's saying as .. i'm not giving you or anyone a way to inject and later remove bits into my kernel. ... you know.. in an auto-update or live system that can get man-in-the-middle'd.

    and no, people past 30..40..50.. depends on intelligence and evilness... do not compromise. if you're suggesting one compromise, you have been compromised yourself. tolerating works however. ;)

    • (Score: 2) by Runaway1956 on Wednesday October 26 2016, @09:46PM

      by Runaway1956 (2926) Subscriber Badge on Wednesday October 26 2016, @09:46PM (#419168) Journal

      I do understand the problems with auto-updating. It was one of the things that turned me off of Ubuntu. I rather like the way my Gentoo runs. I ask it to check for updates. It comes up with three, or three hundred different updates. I can browse the list, and decide which, if any, I want to update. Debian is much the same - or it used to be. SystemD was leveraged in there somewhere, and the updates felt less "optional" after that.

      Auto updating isn't really such a good idea anyway. Your MITM attack is a valid observation, aside from the fact that some updates just don't work as intended.

      I mentioned nvidia drivers, in my last post. I've found it to be foolish to update the drivers immediately after they have been released. Wait a couple weeks, then hit the forums to see how many people are bitching, and about what.

      When I still maintained Windows for the family, there was a service pack for WinXP. I think (almost certain) that it was service pack 2. I grabbed it immediately, and applied it. The computer went into an endless reboot cycle, and I didn't know how to break the cycle. Hit some forums, and learn that SP2 tended to do that to some AMD CPU's. Had I waited a week, then hit the forums before updating, I would have saved myself a lot of bother.

    • (Score: 2) by Geotti on Thursday October 27 2016, @05:01AM

      by Geotti (1146) on Thursday October 27 2016, @05:01AM (#419287) Journal

      i'm not giving you or anyone a way to inject and later remove bits into my kernel. ... you know.. in an auto-update or live system that can get man-in-the-middle'd

      Thanks, I was sure this was blatantly clear.