Recently, Jeffrey Brian Arnold of MIT completed a thesis on a software project entitled ksplice. Ksplice seeks to solve the problem where sometimes systems administrators will wait for weeks to install security patches since they don’t want the downtime of a reboot. Downtime is inconvenient, there were 50 security-only patches released over the last 32 months. Of those, the majority were potential privelege-escalation bugs. These bugs should be the first for patching, but for many systems people, security has traditionally taken a backseat to guaranteeing uptime.

There have been other projects like Ksplice in the past, but they’ve all tried to solve the a very general problem of kernel patching. Ksplice focuses on the problem of patches released purely for security reasons, ignoring the case of general patches from one version to the next. This is a powerful difference, as the majority of security patches are small, and rarely do they touch major data structures. Since Ksplice ignores the case of long-lived data structures, it can’t be used on all patches, but it did work for 42 of the 50 x86 non-DoS security related patches released between 2005 and 2007.

The theory behind KSplice is pretty simple. Determine which functions have changed in the patch, load the new version of the changed functions, and make sure that the never version execute instead of the old. It does this by inserting a ‘trampoline’, or a call to the new version of the function, at the beginning of the old function. This does lead to some additional memory overhead, as both versions of the function will be in memory, but the difference in minimal, and the added benefit of the kernel being patched until you can reboot it is pretty impressive.

The project is also much simpler (and thus more easily portable) than many other projects. It doesn’t try to parse the C code, instead using the GNU Binary File Descriptor Library to examine the binary structure of the compiled object code, using this compiled version to examine each function in memory. As a result, KSlice knows what to replace without having to make any assumptions about what the compiler might do when building the software for real.

Regrettably, the research may be for naught, as it appears that Microsoft may have patented the technique. Now, this patent would probably be pretty easy to overturn, as there is no doubt an immense amount of prior art. Hell the kernel module support in the Linux kernel looks like it could be covered by this patent, and that’s been around since well before 2002. Okay, maybe not exactly, but patenting trampoline functions and binary analysis is pretty ridiculous.

So as not to go into a rant about software patents at this time, I’ll leave it at this: Microsoft’s patent means that no company will touch Ksplice at this time. The patent appears to be one which could be successfully overturned in court, but that takes time and money. And no one has more time and money than Microsoft.

KSplice is a good technology. It solves a good problem for systems administrators, and it appears to do so in a pretty convenient manner. We’ll see how the patent situation plays out, though I don’t expect it’ll turn out well.

From a security standpoint, there is a potential risk, in that if an attacker had already taken advantage of a privilege execution flaw, they could inject almost any code they wanted into the running kernel, however, they already can do this via kernel module loading, which is how KSplice operates, so virtually no security is lost using this technology, and it does make it much easier to keep your kernel patched without worrying about reboots. Speaking of which, I installed a new kernel a few days ago, and I really ought to go reboot…