
Canonical Livepatch - AdamGibbins
http://blog.dustinkirkland.com/2016/10/canonical-livepatch.html
======
cyberpunk
So.... This is ksplice, then?

It sounds hardcore, but this isn't really that complicated is it? Load a
module with a patched function and then modify whatever the kernel equiv of
the GOT/PLT is, and boom -- hotpatch... Right?

Oracle absorbed the kSplice thing though, and I assume the IP around it -- so
unless this does something different to that general procedure, then is there
a possibility of oracle doing their usual crap here?

This is more of a toy than anything though, I recon...

In all my years of adopting and trying to unfuck horribly outdated systems
(not by choice) -- I've never once really wanted or needed to hotpatch a
kernel....

You don't solve your poor architecture decisions by hotpatching running
kernels... If your situation is so bad that a kernel update is the only
solution, and you can't take a box down to do that without an outage on the
platform -- then you need to rethink what you're doing or hire someone who can
do that for you..

~~~
onli
That's a bit critical, isn't it?

Just think of servers. You want to reboot them as seldom as possible, to be
online. But you also want to have critical security patches (or well, just all
security patches) applied as fast as possible. It is already very easy to run
unattended upgrades, and a common practice. Maybe not in a high-class startup
or big enterprise, but everywhere else. With livepatching the kernel you get
the kernel security patches applied immediately, which is very very useful and
will make the linux server more secure in general. And even if your security
practices are perfect, livepatching is still (potentially) easier and faster
and thus a good addition.

> if your situation is so bad that a kernel update is the only solution

I don't get that part, btw. In every situation you always need to update the
kernel when security issues are detected.

~~~
glandium
> I don't get that part, btw. In every situation you always need to update the
> kernel when security issues are detected.

Not the GP, but he means that if you can't take downtime on a server to reboot
with an updated kernel, then you have bigger problems than the kernel not
being up-to-date. Because instead of a scheduled reboot, the server could
crash, lose its disks, lose its power, etc. And if you can't take a scheduled
reboot, how do you take those?

~~~
Xiol
Got RAID and UPS, bruh. Norton on the box. Basically invulnerable.

~~~
cyberpunk
Raid? Pah!

Putting your main tablespaces on ramdrives makes them go like 300x faster!!

Redundancy is for cowards, just like unit tests...

</s>

------
sjellis
Note that, for better or worse, this uses proprietary software. From the post:

" Q: Why does canonical-livepatch client/server have a proprietary license? A:
The canonical-livepatch client is part of the Landscape family of tools
available to Canonical support customers. We are enabling free access to the
Canonical Livepatch Service for Ubuntu community users as a mark of our
appreciation for the broader Ubuntu community, and in exchange for occasional,
automatic canary testing."

------
discreditable
This is super neat but since I've moved my Linux servers to virtual I don't
worry about rebooting for patches. The virtual Linux boxes generally reboot in
less than 30s (thank you, systemd). It usually doesn't even register as a blip
on my monitoring software. When I have to reboot the host, that's a 5–10
minute ordeal while the BIOS/UEFI and storage controllers initialize.

------
IgorPartola
I still don't understand why they want to bypass APT here. I saw the FAQ about
this and it still doesn't make sense to me and just feels like some kind of a
lock-in attempt.

~~~
fragmede
There are a couple pieces to that, not the least of which is Canonical wanting
to push their new 'snap' format, for better or worse. The other thing is that
Apt is not a good fit for the task - say it's daemonized programs instead of
live patches. Apt only takes responsibility for downloading the bits onto the
machine and unpacking them, and init/systemd is responsible for actually
running programs.

However, for live patches, it's critical the program be running/the patch
installed, and Apt doesn't manage running processes, nor does it have a UI
whos purpose is to report on patches that have successfully downloaded but
fail to install. These aren't fatal problems, but those aren't features
upstream apt is likely to want (maybe systemd wants to swallow apt), so then
you're forking apt, with all the work that entails. Might as well just write
your own thing in that case.

~~~
IgorPartola
But APT does. It can run the post-install script for the package, which can
certainly include the live-patching bits. It's not like live-patching needs a
continuously running daemon.

Saying that APT can't do this is nearly equivalent to saying that APT should
not be trusted to run any post-install scripts at all, which basically means
it shouldn't be trusted to install half the software out there.

