XFI: Software Guards for System Address Spaces
´Ulfar Erlingsson
Microsoft Research
Silicon Valley
Martı´n Abadi
Microsoft Research
Silicon Valley
& UC Santa Cruz
Michael Vrable
UC San Diego
Mihai Budiu
Microsoft Research
Silicon Valley
George C. Necula
UC Berkeley
Abstract
XFI is a comprehensive protection system that offers
both flexible access control and fundamental integrity
guarantees, at any privilege level and even for legacy
code in commodity systems. For this purpose, XFI com-
bines static analysis with inline software guards and a
two-stack execution model. We have implemented XFI
for Windows on the x86 architecture using binary rewrit-
ing and a simple, stand-alone verifier; the implementa-
tion’s correctness depends on the verifier, but not on the
rewriter. We have applied XFI to software such as device
drivers and multimedia codecs. The resulting modules
function safely within both kernel and user-mode address
spaces, with only modest enforcement overheads.
1 Introduction
XFI is a comprehensive software protection system that
supports fine-grained memory access control and funda-
mental integrity guarantees for system state. XFI offers
a flexible, generalized form of software-based fault iso-
lation (SFI) [25, 36, 41] by building on control-flow in-
tegrity (CFI) [1, 2] at the machine-code level. This CFI
foundation enforces external and internal interfaces, en-
ables efficient XFI mechanisms, and helps protect the in-
tegrity of critical state, such as the x86 control registers.
In comparison with other protection alternatives, XFI
requires neither hardware support [39, 44] nor type-safe
programming languages [5, 19, 24]. XFI does not restrict
memory layout and is compatible with system aspects
such as signals and multi-threading. Furthermore, XFI
applies at any privilege level, and even to legacy code
that is run natively in the most privileged ring of x86
systems; in this respect, we regard XFI as achieving an
important practical goal.
XFI has a clear architecture, whose basic implemen-
tation can be relatively straightforward and trustworthy.
XFI protection is established through a combination of
static analysis with inline software guards that (much
as in SFI) perform checks at runtime. The XFI verifier
performs the static analysis as a linear inspection of the
structure of machine-code binaries; it ensures that all ex-
ecution paths contain sufficient guards before any pos-
sible protection violation. Verification is simple and, in
principle, amenable to formal analysis and other means
of assuring correctness. An XFI module is an executable
binary that passes verification; such modules can be cre-
ated by hand, by compile-time code generation, or by
binary rewriting. However, software that hosts XFI mod-
ules need trust only the verifier, not the means of module
creation. Thus, XFI modules can be seen as an example
of proof-carrying code (PCC) [29], even though they do
not include logical proofs.
XFI protection relies on several distinct runtime mech-
anisms, whose correct use is established by the XFI ver-
ifier. Guards ensure that control flows only as expected,
even on computed transfers, and similarly that memory
is accessed only as expected. Multiple memory accesses
can be checked by a single memory-range guard, opti-
mized for fast access to the most-frequently-used mem-
ory. XFI also employs two stacks. The regular execution
stack provides a scoped stack, which holds data accessi-
ble only in the static scope of each function, including
return addresses and most local variables. The scoped
stack cannot be accessed via computed memory refer-
ences, such as pointers; therefore, it serves as isolated
storage for function-local virtual registers. A separate
allocation stack holds other stack data which may be
shared within an XFI module. Like heap memory, the al-
location stack may be corrupted by buffer overflows and
other pointer errors.
XFI protection can be of benefit to any host system
that loads binary modules into its address space to make
use of their functionality. Operating systems are exam-
ple host systems, as are web browsers. Conversely, those
modules may rely on their host system, by invoking its
1