05-05-2012, 01:48 PM
Ksplice: Automatic Rebootless Kernel Updates
kspliceStudyMaterial.pdf (Size: 392.9 KB / Downloads: 65)
Introduction
Contemporary operating systems regularly release kernel
patches to repair security vulnerabilities. Applying these
patches typically requires rebooting the kernel, which results
in downtime and loss of state (e.g., all network connections).
Even when computer redundancy is available, rebooting
can lead to momentary interruption or cause unexpected
complications, which means that reboots are commonly specially
scheduled and supervised. Since rebooting is disruptive,
many system administrators delay performing these updates,
despite the greatly increased security risk—more than
90% of attacks exploit known vulnerabilities [Wang 2004].
This paper describes and evaluates Ksplice, a system for using
traditional source code patches to construct hot updates,
which change the running kernel.
The key novelty of Ksplice is that it prepares hot updates
at the object code level instead of the source code level,
which allows Ksplice to perform hot updates with minimal
programmer involvement. Existing hot update practices, described
in Section 7, rely on a programmer to write source
code files with certain properties (e.g., [Chen 2006, Makris
2007]) or require manual inspection of the running binary to
achieve safety guarantees and resolve ambiguous symbols
(e.g., [Altekar 2005]) . Significant programmer involvement
in creating a hot update increases both the cost and the risk of
the update, which discourages the adoption of hot updates.
Ksplice therefore performs hot updates for legacy binaries
(unmodified binaries created without foresight of the update
system) based entirely on existing information, such as a
source code patch.
Design Overview
Many source code patches can be transformed into hot updates
without a programmer writing any new code. Specifically,
a patch alone provides sufficient information for a hot
update when the patch does not make semantic changes to
the kernel’s persistent data structures—that is, changes that
would require existing instances of kernel data structures to
be transformed (e.g., a patch that adds a field to a data structure
would require existing instances of that data structure to
change).
Ksplice requires a programmer to check whether the target
patch makes any semantic changes to data structures.
Performing this check requires only seconds or a few minutes
for most security patches. If a patch does make semantic
changes, then that update can still be applied using Ksplice,
but doing so will require a programmer to write some new
code.
Motivation and challenge
One advantage of operating at the object code layer is that
the code changes implied by a patch are readily apparent at
the object code layer. Consider a patch that changes a data
type in a function prototype in a C header file (e.g., from an
int to a long long). Because of implicit casting, this patch
implies changes to the executable code of any functions that
call the prototyped function. By operating at the object code
layer, Ksplice detects these changes without needing any
information about the semantics of implicit casting in C. In
contrast, if one operates at the source code layer, one would
find that the callers of the prototyped function have not had
their source code modified at all, even after C preprocessing.
Looking for object code differences does not require special
cases in order to deal with language-level nuances such
as implicit casting, function signatures, static local variables,
and whether code is written in C or assembly. The object
code differences, unlike the source code changes, already
express what we actually care about—how and where the
machine’s execution might be changed.
run-pre matching
This section introduces run-pre matching, which addresses
two problems: how to resolve symbols in the replacement
code and how to verify the safety of an update (if an update
would be unsafe, run-pre matching will abort the update).
We first discuss the challenges in addressing the two problems
and then present run-pre matching.
Challenge of resolving symbols
Any hot update system needs to resolve symbols into addresses
in order to fulfill relocations in the replacement code.
A simple way to resolve symbols is to use an available
symbol table, such as the Linux kernel’s kallsyms symbol
table. Unfortunately, attempting to resolve symbols based
on entries in a symbol table will commonly cause problems
when a symbol name appears more than once or does not
appear at all.