Say Goodbye to Reboots with Ksplice
Anything that can be applied also can be reversed, and the Ksplice tools let you do this easily. To undo an update, simply run ksplice-undo with the update's ID, like so:
# ksplice-undo 8c4o6ucj
If this process succeeds, a message will show up in the kernel's log:
# dmesg | tail -n1 ksplice: Update 8c4o6ucj reversed successfully
If you forget the update ID, fear not. ksplice-view will list the Ksplice updates currently installed on your system.
Under the hood, reversing an update is very similar to applying an update. Ksplice finds the old and new functions, and at a safe time, it removes the trampoline. Now, all callers of the old function will continue to get the old function. In the context of a removal, a safe time is determined as it was before, except now Ksplice makes sure that the new code is not in use. Because the tarball contains the old code, it's easy for Ksplice to determine with what code to replace the trampoline.
Determining which updates are installed is also easy. Remember that the new code gets into the kernel by being loaded as a module. As a result, it appears in the lsmod output, which ksplice-view can examine.
Can this technology really be used to keep production machines up to date for extended periods of time? Absolutely. In fact, a Ksplice evaluation of all of the serious Linux security vulnerabilities between May 2005 and May 2008 shows that all of them can be applied as rebootless updates.
However, there is a caveat: a programmer needs to write a small amount of additional code (about 17 lines per patch, on average) for about 12% of these patches. So what sorts of patches require this additional code, and why?
Let's say that we find a bug in a kernel function that gets called only when the machine is booting and never gets called again. Let's say that this function was supposed to set a flag, but doesn't.
We can create a Ksplice update that fixes the function, but that doesn't really accomplish anything, because the function never will be called again (so the bug never will be corrected).
Instead, a kernel programmer needs to write some additional code that transforms the state of the kernel to correct the bug. In this case, the update will need to set the flag when it is applied.
However, determining whether a patch is safe to apply without additional code is tricky, as is writing the additional code. In general, patches that change initialization values or add new fields to data structures require additional code, but this is not a hard-and-fast rule. As a result, you should not construct your own Ksplice updates for use on production systems unless you are an experienced kernel developer.
That said, you still can reap the benefits of this new technology by using the Ksplice Uptrack service without having to do any of the work, because the Ksplice Uptrack folks have done it for you.
Rebootless updates represent an exciting step forward—and, with Ksplice Uptrack, Linux is the first mainstream operating system that does not require reboots for security updates, ever.
So, say goodbye to reboots, and keep working on that high score of yours.
About the Ksplice Uptrack service, including instructions for installing and getting started with the service: www.ksplice.com/uptrack.
Sign up for the Ksplice mailing list if you're interested in hearing more: lists.ksplice.com.
A detailed technical paper on the internals of Ksplice's core technology: www.ksplice.com/paper.
Waseem Daher is a cofounder of Ksplice. He lives and works in Cambridge, Massachusetts, and can be reached at email@example.com.
- One Port to Rule Them All!
- How to Deliver Hybrid Apps in 2 Weeks [Webcast]
- Privacy Is Personal
- PHP for Non-Developers
- Secure Server Deployments in Hostile Territory
- Linux Kernel 4.1 Released
- Django Templates
- July 2015 Issue of Linux Journal: Mobile
- A Code Boot Camp for Underprivileged Kids
- Practical Books for the Most Technical People on the Planet