Canonical Livepatch Service Automatically Updates Ubuntu 16.04 LTS (and later) with the Latest Kernel without Rebooting

Installing or upgrading packages in Linux distributions does not normally require rebooting your system, except for the Linux kernel and drivers. But since Linux 4.0 kernel, Live Kernel patching is possible, meaning Linux kernel updates can be performed without having to reboot your server or computer. Canonical is now taking advantage of this new feature with their Livepatch Service available for Ubuntu 16.04 LTS and greater.

canonical_livepatchIf you want to enable it on your machine, you’ll have to authenticate to Livepatch portal to get a key / token for the service as shown in the screenshot above.

Now you can install the service:


and enable it with your token:


That’s it. Your can check Livepatch service status with the command:


In my case, an update was not necessary, but if there’s one you should see something like:


That way you can make sure your system always have the latest security patchsets. This is mostly useful for servers, but it might not be a bad idea to enabled for your computer too, especially it’s free for end-users for up to 3 machines. Companies need to apply to Ubuntu Advantage for business to support more machines.

Support CNX Software - Donate via PayPal or become a Patron on Patreon

15
Leave a Reply

avatar
14 Comment threads
1 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
7 Comment authors
DroneSimoscnxsoftRKtkaiser Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
zoobab
Guest

Looks like a proprietary service.

Otherwise, fx8350 is a fast cpu?

Sander
Guest
Sander

I thought Ubuntu’s ‘snap’ was like docker, so it couldn’t do anything outside its container.

But now I see that with a snap package you can even patch the kernel of the host, so my assumption was apparently false.

tkaiser
Guest
tkaiser
zoobab
Guest

Closed source:

” The source code of the canonical-livepatch client is part of Canonical’s Landscape system management product and is commercial software”

RK
Guest
RK

@zoobab

If memory serves, livepatch builds on the common APIs of kpatch and kgraft that were originally developed and released separately in 2014 by Red Hat and Suse and were submitted for mainlining as a single common live patching core APIs in 2015. They’re FOSS implementations of ksplice (2008).

Currently, Arch and Ubuntu use livepatch, Suse uses kgraft and Red Hat Enterprise Linux uses kpatch. Features wise, kpatch and kgraft are on parity while livepatch is slightly lagging behind. Performance wise, kgraft is the fastest. However, kpatch is a little safer in theory.

Overall, there’s some kernel work going around to make live patching a bit more ubiquitous outside the x86 world.

zoobab
Guest

Does it work on ARM as well?

Simos
Guest
Simos

@zoobab

Here is the launchpad page for the client, https://launchpad.net/canonical-livepatch-client
It is indeed closed-source.

The kernel livepatch functionality is available in the kernel, and what Canonical is providing is an easy/secure/tested way to apply those updates, on the stock Ubuntu kernel. Such a feature makes a lot of sense to paying customers that run servers.

It is always possible for someone to create on their own (for free) those livepatch updates and apply them.

tkaiser
Guest
tkaiser

So the users that join the free livepatch service are the beta-testers (“Once a livepatch passes CI/CD and regression tests, it’s rolled out on a canary testing basis, first to a tiny percentage of the Ubuntu Community users of the Canonical Livepatch Service.”) and if anyone ever wants to deploy a rootkit in critical infrastructure he’ll attack this proprietary service.

Zoobab
Guest

@tkaiser
+1 for a rootkit.

Drone
Guest
Drone

This locked-down proprietary crap with deep reach into the system you once thought YOU controlled is a honeypot for attackers. Canonical is not only stupid, they’re Evil!

tkaiser
Guest
tkaiser

@Drone
The funny thing is that this service targets service providers who want to minimize downtimes since they provide LXD containerization (Ubuntu Cloud): https://www.ubuntu.com/cloud/lxd

Since all containers share the same kernel it gets really interesting to attack such instances since one single rootkit owns a few hundred LXD instances or a few thousand Docker containers 🙂

In a world where people install devices in their households that send every spoken word or pictures/videos to the cloud who should wonder that there are proprietary services running inside the kernel securely communicating and receiving ‘patches’ from somewhere else. Madness everywhere 😉