Got a few multiuser systems for which scheduling an occasional reboot is a major PITA. Wondering if the ksplice solution is as painless as it sounds or there are tradeoffs I just haven't learned of yet...

I think that you need to subscribe to a service to use it. Also there may be security concerns. If you enable live patching of the kernel, couldn't a blackhat do the same to install his custom rootkit?

(Disclaimer: I work for Ksplice)

That's correct.

We have a completely free version for Ubuntu Desktop and Fedora (https://www.ksplice.com/uptrack/download), and then the other distributions have a 30-day free trial.

This isn't correct. You don't need to boot into a custom kernel or enable some sort of live patching feature to use Ksplice. We can start running on the system you already have -- the ability to live patch the kernel is one that's inherent to being root and being able to load modules on the system.

So in short, no, there is no security concern here. If anything, your security is much improved, since you're now able to apply important security patches much sooner than you would otherwise have been able to.

Hi, thanks for the reply. One part I don't understand is how does getting kernel patches from ksplice coexist with patches coming through standard channels (APT/YUM)?

Yeah, that's a good question.
Ksplice Uptrack only updates the kernel, and only does so in memory.
The package manager continues to be responsible for updating all of your packages on disk (including the kernel image on disk).

So they're complementary.

Most of our customers will:
- Use the package manager to upgrade the kernel (but they don't reboot afterwards)
- Then also use "uptrack-upgrade" to upgrade the kernel in memory

Now you're secure and up-to-date in your running system, and if you later have to reboot for some reason, you have the option of booting into the new, "traditionally updated" kernel image on disk.

Thanks for that, it's starting to make sense to me now.

All "official" kernel patches come from kernel.org, right? So there would never be a situation where the patch one gets through Ksplice Uptrack is different from what one gets from the distribution maintainers, correct?

Actually, it's even better: we ONLY take the patches that your vendor has released.

For example, on RHEL: When Red Hat releases a new kernel, only then do we go and look at that kernel and make the important security and bugfix updates rebootless (and then we deliver them to you). So you're actually getting the same updates as released by your vendor, but you're getting them in rebootless form.

(In other words, you're not getting some patches we're making up, or anything like that - they all come from the vendor.)

Sounds good, thanks. The machines I'm researching this is for are running Debian Lenny and I probably won't get around to upgrading to Squeeze till later this year. Will Ksplice continue to support Lenny as long as Debian will continue releasing security patches for it?

One other question on this. What's the typical delay between when the vendor releases a patch and when it becomes available through Ksplice? Does it depend on how much programming effort is involved on your part and varies from patch to patch or there's a fixed release schedule of +1 day, etc?

That's the plan, yep.

Typically about 24 hours.