Ksplice allows system administrators to apply security patches to the Linux kernel without having to reboot. Ksplice takes as input a source code change in unified diff format and the kernel source code to be patched, and it applies the patch to the corresponding running kernel. The running kernel does not need to have been prepared in advance in any way.
To be fully automatic, Ksplice's design is limited to patches that do not introduce semantic changes to data structures, but most Linux kernel security patches don't make these kinds of changes. An evaluation against Linux kernel security patches from May 2005 to December 2007 finds that Ksplice can automatically apply 84% of the 50 significant kernel vulnerabilities from this interval.
Ksplice has been implemented for Linux on the x86-32 and x86-64 architectures. Please be aware that this software is quite new, and it might contain bugs that could cause severe problems. The code is available in a Git repository, as a source code tarball, as an x86-32 binary distribution tarball, and as an x86-64 binary distribution tarball. Building the source code requires the GNU BFD library from GNU Binutils, which is available in Debian (as binutils-dev) and in other Linux distributions. Ksplice is free software; you can redistribute and/or modify it under the terms of the GNU General Public License, version 2.
If you'd like to try Ksplice, instructions are available for installing Ksplice and making a sample modification to a running kernel.
On July 12, 2006, the Linux kernel developers committed the following security patch to the mainline Linux kernel, protecting against CVE-2006-2451, a significant vulnerability involving the kernel's sys_prctl function:
diff --git a/kernel/sys.c b/kernel/sys.c
index dbb3b9c..e236f98 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1983,7 +1983,7 @@ asmlinkage long sys_prctl(int option, unsigned long arg2, unsigned long arg3,
error = current->mm->dumpable;
break;
case PR_SET_DUMPABLE:
- if (arg2 < 0 || arg2 > 2) {
+ if (arg2 < 0 || arg2 > 1) {
error = -EINVAL;
break;
}
Normally, a system administrator would need to reboot in order to conveniently apply this kind of update to a Linux system.
Ksplice allows this kind of update to be applied with the following commands. This example assumes that the source code for the running kernel, 2.6.16, is already unpacked in ~/linux-source and that the security patch above is in the file ~/prctl.
user@localhost:~$ mkdir ~/linux-source/ksplice user@localhost:~$ cp /boot/config-2.6.16-1-686-smp ~/linux-source/ksplice/.config user@localhost:~$ cp /boot/System.map-2.6.16-1-686-smp ~/linux-source/ksplice/System.map user@localhost:~$ ksplice-create --patch=./prctl ~/linux-source/ksplice Ksplice update tarball written to ksplice-bzrz1v2h.tar.gz [the user should then become root] root@localhost:/home/user# ksplice-apply ./ksplice-bzrz1v2h.tar.gz Done!
The first three lines provide Ksplice with information about the kernel's original configuration, which is needed in order to construct the update. Ksplice expects to be provided with the original kernel's .config file and System.map file, but these files are essentially always easily available (most Linux distributions put them in /boot or distribute them with the kernel source).
After ksplice-apply has printed "Done!", the update has been applied to the running kernel, and the system is no longer subject to this security vulnerability.
More details about how Ksplice works and how it has been evaluated are available in this Ksplice technical overview document.
In addition to the evaluation described in that document, Ksplice has been tested on Linux kernel versions ranging from 2.6.8 to 2.6.25, and on several Linux distributions, including Debian, Ubuntu, RHEL, Gentoo, and ASP Linux.
In addition to patching security vulnerabilities, Ksplice can also be used to add debugging code to the kernel or to make any other code changes that do not modify data structure semantics. For example, you can use Ksplice to modify the behavior of printk.
Q: What kinds of patches can't Ksplice handle? Why can't Ksplice handle these patches?
A: Ksplice cannot handle semantic changes to data structures—that is, changes that would require existing instances of kernel data structures to be transformed. For example, a patch that adds a field to a global data structure would require the existing data structures to change. We examined 32 months of Linux kernel patches and found that most (42 out of 50) kernel security patches do not require such semantic changes.
The design choice to not handle semantic changes avoids burdening the hot update creator with writing code to transform the original kernel data structures to the state expected by the new code. An imperfect state transformation function could lead to disastrous consequences, so avoiding this source of effort and potential for human error makes sense until hot update systems are more widely deployed.
Q: Doesn't Ksplice help bad guys introduce non-GPL code in the kernel and/or create malware?
A: The bad guys already know how to accomplish their goals using ad hoc kernel inspection and modification techniques. If someone wanted to get around EXPORT_SYMBOL_GPL, there are simpler ways to do so than using Ksplice.
If you have any questions, complaints, comments, bug reports, or patches, please send them to me at jbarnold@mit.edu or ksplice@mit.edu.