in 2008 as a project
for "rebootless kernel security updates" based at MIT. The students behind
the project soon graduated, and so did the project itself; a company by the
same name was formed to offer commercial no-reboot patching to customers
who cared deeply about uptime. Ksplice Inc. also offered free update services
for a number of distributions. Much of this came to an end on
July 21, when Oracle announced
that it had acquired Ksplice Inc. and would incorporate its services into its
own Linux support offerings. A free form of ksplice might just live on,
though, with support from an interesting direction.
On the same day that Oracle announced the acquisition, CentOS developer
Karanbir Singh suggested that one place the
CentOS community could help out would be in the creation of a ksplice
update stream. CentOS updates had been available from Ksplice Inc., on a
trial basis at least; the company even somewhat snidely let it be
known that they were providing updates for CentOS during the first few
months of 2011, when the CentOS project itself had dropped the ball on that job.
Oracle-ksplice still claims to
support CentOS, but there is not even a trial service available for free;
anybody wanting update service for CentOS must pay for it from the
beginning. (The free service for Fedora and Ubuntu appears to still be
functioning, for now - but who builds a high-availability system on those
It is hard to blame Oracle too much for this decision. Oracle has bought a
company which, it believes, will make its support offerings more
attractive. Making the ksplice service available for free to CentOS users,
in the process making CentOS
more attractive relative to commercial enterprise offerings, would tend to
undercut the rationale behind the entire
acquisition. While it would certainly be a nice thing for Oracle to
provide a stream of ksplice updates for CentOS users, that is not something
the company is obligated to do.
So if CentOS is to have an equivalent service, it will have to roll its
own. There are a few challenges to be overcome to bring this idea to
fruition, starting with the ksplice code itself. That code, by some
strange coincidence, disappeared from the Ksplice Inc. site just before the
acquisition was announced. The Internet tends not to forget, though, so
copies of this code (which was released under the GPL) were quickly
located. Karanbir has posted a repository containing
the ksplice 0.9.9 code as a starting place; for good measure, there
are also mirrors on gitorious and github.
Getting the ksplice code is the easy part; generating the update stream
will prove to be somewhat harder. Ksplice works by looking at which
functions are changed by a kernel patch; it then creates a kernel module
which (at runtime) patches out the affected functions and replaces them
with the fixed versions. Every patch must be examined with an eye toward
what effects it will have on a running kernel and, perhaps, modified
accordingly. If the original patch changes a data structure, the
rebootless version may have to do things quite differently, sometimes to
the point of creating a shadow structure containing the new information.
And, naturally, each patch in the stream must take into account whatever
previous patches may have been applied to the running kernel.
Some more information on this process can be found in this article from late 2008. The point,
though, is that the creation of these runtime patches is not always a
simple or mechanical process; it requires real attention from somebody who
understands what the original patches are doing. CentOS has not
always been able to keep up with Red Hat's patch stream as it is; the
creation of this new stream for kernel patches will make the task harder.
It is not immediately obvious that the project will be able to sustain that
extra effort. If it does work out, though, it would clearly make CentOS a
more attractive distribution for a number of high-uptime use cases.
An interesting question (for those who are into license lawyering, anyway)
is whether a patch in Oracle's ksplice stream constitutes a work derived
from the kernel for which the source must be provided. Having access to
the source for Oracle's runtime patches would obviously facilitate the
process of creating CentOS patches.
Even if a credible patch stream can be created, there is another challenge
to be aware of: software patents. The Ksplice Inc. developers did not
hesitate to apply for patents on their work; a quick search turns up these
The first of these has a claim reading simply:
A method comprising: identifying a portion of executable code to be
updated in a running computer program; and determining whether it
is safe to modify the executable code of the running computer
program without having to restart the running computer program.
That is an astonishingly broad claim, even by the standards of US software
patents. One should note that both of the applications listed above are
exactly that: applications. Chances are that they will see modifications
before an actual patent is granted - if it is granted at all. But the US
patent office has not always demonstrated a great ability to filter out
patents that overreach or that are clearly covered by prior art.
Once again, license lawyers could get into the game and debate whether the
implied patent license in the GPL would be sufficient to protect those who
are distributing and using the ksplice code. Others may want to look at
Oracle's litigation history and contemplate how the company might react to
a free service competing with its newly-acquired company. There are other
companies holding patents in this area as well. Like it or not,
this technology has a potential cloud over it.
It all adds up to a daunting set of challenges for the CentOS project if it
truly chooses to offer this type of service. That said, years of watching
this community has made one thing abundantly clear: one should never
discount what a determined group of hackers can do if they set their minds
to a task. A CentOS with no-reboot kernel updates would be an appealing
option in situations where uptime needs to be maximized but there are no
resources for the operation of a high-availability cluster. If the CentOS
community wants this feature badly enough, it can certainly make it happen.
to post comments)