Beyond the PDP-11: Architectural support

for a memory-safe C abstract machine

David Chisnall Colin Rothwell Brooks Davis Peter G. Neumann

Robert N. M. Watson SRI International
Jonathan Woodruff Munraj Vadera {brooks,neumann}@csl.sri.com
Simon W. Moore Michael Roe
University of Cambridge
[email protected]

Abstract range of sizes, behaviors, and representations of primitive

We propose a new memory-safe interpretation of the C ab- types. A fully specified abstract machine for a language en-
stract machine that provides stronger protection to benefit capsulates all assumptions that are safe for a programmer to
security and debugging. Despite ambiguities in the specifi- make about every possible implementation of the language.
cation intended to provide implementation flexibility, con- Concrete implementations may perform native compila-
temporary implementations of C have converged on a mem- tion to machine code, provide a virtual machine with a com-
ory model similar to the PDP-11, the original target for C. plete environment, or choose an intermediate step with com-
This model lacks support for memory safety despite well- plex parts of the system implemented as operating-system
documented impacts on security and reliability. or library routines. The last approach is the most common
Attempts to change this model are often hampered by as- for the C language, with memory allocation and certain
sumptions embedded in a large body of existing C code, dat- complex floating-point operations implemented in shared li-
ing back to the memory model exposed by the original C braries, but most language constructs compiled directly to
compiler for the PDP-11. Our experience with attempting to short sequences of machine instructions. A key aspect of
implement a memory-safe variant of C on the CHERI ex- mapping the abstract model onto a target platform is the
perimental microprocessor led us to identify a number of memory model, which defines (among other things) how ab-
problematic idioms. We describe these as well as their in- stract ideas of pointers and objects (ranges of memory with
teraction with existing memory safety schemes and the as- an associated type) are represented on the target—for exam-
sumptions that they make beyond the requirements of the C ple, as words and ranges of bytes in a flat address space.
specification. Finally, we refine the CHERI ISA and abstract The C abstract machine was originally designed to be
model for C, by combining elements of the CHERI capabil- sufficiently close to the PDP-11 that a simple compiler
ity model and fat pointers, and present a softcore CPU that could achieve good performance translating C statements
implements a C abstract machine that can run legacy C code into short sequences of PDP-11 instructions. The abstract
with strong memory protection guarantees. machine was subsequently extended to allow very differ-
ent implementations. Early targets included the Honeywell
6000, IBM System/370, and Interdata 8/32 [25]. In spite of
1. Introduction this generalization, most contemporary computers designed
A programming language defines both a concrete syntax and to support C programs utilize instruction sets that are rem-
an abstract machine. The abstract machine describes the en- iniscent of the PDP-11, particularly in terms of memory
vironment that a programmer should expect, such as the model. The PDP-11 model is appealing due to its simplicity
and its portability; however, lack of memory-safety proper-
Permission to make digital or hard copies of all or part of this work for personal or
ties leaves code compiled to that model subject to memory
classroom use is granted without fee provided that copies are not made or distributed corruption in the face of bugs. More concerningly, these
for profit or commercial advantage and that copies bear this notice and the full citation bugs frequently prove exploitable by attackers with broad
on the first page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or scope for malicious data and control-flow modification [29];
republish, to post on servers or to redistribute to lists, requires prior specific permission for example, CWE/SANS lists “Classic Buffer Overflow”,
and/or a fee. Request permissions from [email protected].
ASPLOS ’15, March 14–18, 2015, Istanbul, Turkey. possible due to lack of memory safety, as the third most
Copyright is held by the owner/author(s). Publication rights licensed to ACM. dangerous software error [21].
ACM 978-1-4503-2835-7/15/03. . . $15.00.
http://dx.doi.org/10.1145/2694344.2694367
 Bugs with respect to the abstract language model may be memory safety is a building block for higher-level security
vulnerabilities, but the degree to which they are exploitable abstractions in Java.
by attackers depends on concrete implementation choices
such as stack layout [2]. Refinements to language implemen-
2. Common idioms
tations (such as memory protection) therefore offer opportu-
nities to mitigate vulnerabilities as well as make debugging The CHERI ISA [33] introduces memory safety to a RISC
easier [26]. The potential benefits of bounds checking and ISA by supplementing general-purpose registers with ca-
other integrity techniques have been well documented by pability registers and tagged memory, drawn from the
work such as Cyclone [17], CCured [23], SoftBound [22], capability-system model, providing strong integrity protec-
HardBound [12], and CHERI [35]. Deployment of these tion and bounds checking for pointers. In attempting to im-
techniques is hampered not just by performance concerns plement a C compiler for early versions of the CHERI ISA,
but also by whether current software relies on specific im- we found that it was very easy to support well-behaved C
plementation choices. Evaluation cases have frequently been code. On attempting to compile nontrivial C programs, we
limited to benchmarks and application software that might discovered a number of programs failed to either compile
be termed “extremely well-behaved C” rather than the low- or run correctly, due to different interpretations of the C ab-
level software that would most benefit from their support stract machine. We collected examples of these failures and
(e.g., buffer-centered packet parsing). produced the following taxonomy of common C idioms that
Understanding and addressing the practical effects of are difficult for memory-safe implementations to support.
stronger memory models is critical in deploying them to mit- To explore the extent to which existing programs depend
igate vulnerabilities. We therefore propose a new interpreta- on a traditional view of memory, we modified the Clang
tion of the C abstract machine that affords stronger memory- compiler to identify potentially problematic pointer oper-
protection properties. We evaluate this approach against ex- ations, as well as code that removes the const qualifier.
isting C-language corpora and a practical implementation LLVM intermediate representation (IR) is typed, with point-
via our open-source Capability Hardware Enhanced RISC ers and integers being distinct. Type-safe pointer arithmetic
Instructions (CHERI) softcore processor. is performed by the GetElementPtr instruction. The PDP-
We first investigate how commonly held assumptions 11 model allows arbitrary arithmetic to construct valid ad-
about pointer behavior go beyond the rules mandated by dresses in a flat address space, but is incompatible with
the C abstract machine, at times incorporating implicit as- memory safety that requires a substrate to be aware of ob-
sumptions regarding the PDP-11 memory model. We do this jects and enforce bounds checking. We can detect assump-
by surveying a variety of pointer-centered C idioms using tions of the PDP-11 model (and violations of the type sys-
an LLVM-based static analyzer over a large open-source ap- tem), as LLVM must generate ptrtoint and inttoptr in-
plication corpus. This allows us to identify a tradeoff space struction pairs that turn a pointer into an integer, perform
between protection and compatibility. Next, we link these arithmetic, and then convert it back.
ideas to portions of the C abstract machine—as described in Our modified LLVM identified all instances of pointer
the C11 specification [16]—that are implementation defined, arithmetic that survive optimization and performed some
investigating the possible implementation space. simple categorization. We ignore those that do not survive
We discuss the problems with supporting these idioms optimization because they will have no effect on run-time
on existing models, including our CHERI ISA (a RISC enforcement. We compiled a sample corpus of around 2M
instruction-set architecture that implements fine-grained lines of popular C code with this modified compiler, cate-
memory protection). We propose a refinement to the CHERI gorized violations by inspecting the code, and extracted test
ISA, CHERIv3 [34], informed by state-of-the-art hardware- cases demonstrating the common patterns.
assisted fat-pointer schemes, to improve software compati- Table 1 shows a summary of the total number of occur-
bility. We evaluate performance and compatibility with re- rences of each of the idioms that we have identified. Some
spect to both hardware and software by implementing two of these are entirely valid within the C memory model, some
capability-based memory models and exploring the impact depend on implementation-defined behavior, and some de-
(including lines-of-code changes) on a set of C-language pend on undefined behavior that happens to be implemented
applications, relative to the PDP-11 memory model. in a specific way on common compilers.
We demonstrate that it is possible for a memory-safe im- Note that these values are a result of machine-assisted
plementation of C to support not just the C abstract machine human categorization, and are intended to be indicative of
as specified, but a broader interpretation that is still compati- the frequency of these idioms rather than accurate measures.
ble with existing code. By enforcing the model in hardware, Breaking these idioms will break existing code, and our
our implementation provides memory safety that can be used analysis gives a rough idea of the scope of such breakage.
to provide high-level security properties for C TCBs, just as Unlike prior work, such as STACK [32], we are not look-
ing purely for cases where programs rely on undefined be-
havior and therefore work only coincidentally. We are also
 P ROGRAM D ECONST C ONTAINER S UB II I NT IA M ASK W IDE LOC
ffmpeg 150 0 800 4 0 0 4 0 693,010
libX11 117 0 19 9 1 0 0 5 120,386
FreeBSD libc 288 0 216 2 13 50 184 17 136,717
bash 43 0 207 11 0 0 15 4 109,250
libpng 20 0 175 1 0 0 0 0 50,071
tcpdump 579 0 9 1299 0 0 0 0 66,555
perf 575 151 46 0 53 151 31 4 52,033
pmc 2 0 0 0 18 0 0 0 8,886
pcre 98 0 52 0 0 0 0 0 70,447
python 494 0 358 1 109 0 131 8 383,813
wget 55 0 61 0 3 0 1 10 91,710
zlib 4 0 24 0 0 0 0 0 21,090
zsh 29 0 267 0 0 0 5 5 98,664
T OTAL 2491 151 2236 1557 197 201 371 53 1,902,632

Table 1. Summary of difficult idioms in popular C packages.

looking for cases where programs rely on implementation- structure [20]. This may or may not be permitted behav-
defined behavior related to a specific understanding of the ior according to the standard, due to the ambiguous def-
machine’s memory model, and thus would be fragile in the inition of ‘object’. Use of this idiom would break with
presence of different interpretations. When a compiler en- any implementation that associates strict bounds check-
counters undefined behavior, it is free to do whatever it ing with a pointer based on its static type, but not one that
wishes. For example, if the value of a is the result of un- employs the bounds of the original object.
defined behavior, then it is acceptable for the compiler to This is a special case of pointer subtraction, but its
optimize a == b and a != b to the same value. In contrast, use breaks assumptions that we would like to make for
implementation-defined behavior must be self-consistent. pointer bounds: A compiler can statically insert bounds
For example, the value of sizeof(int) is implementation information on a pointer to a structure field, which can be
defined and may be 4, 8, or some other value, but must be enforced by the underlying substrate—preventing some
consistent within a program. categories of pointer error with a fine granularity.
We assume that all of the code that we inspected works
correctly, that all of the idioms that we find are intentional, Sub refers to any arbitrary pointer subtraction. High-level
and that the code depends on them working as expected. We languages commonly lack pointer subtraction, preferring
identified the following idioms: a model where pointers are always references to objects
(a base and a bounds), and accesses to object fields or ar-
Deconst refers to programs that remove the const qualifier ray elements require that the programmer have a pointer
from a pointer. This will break with any implementation to the object. With pointer subtraction, bounds checking
that enforces the const at run time. §6.7.3.4 [16] states: requires an offset as well as the base and bounds and so
If an attempt is made to modify an object defined with bounds-checked pointers are larger.
a const-qualified type through use of an lvalue with non- II refers to computation of invalid intermediate results. The
const-qualified type, the behavior is undefined. C specification allows pointers to point one element after
This means that such removal is permitted unless the the end of an array, but not be dereferenced when point-
object identified by the pointer is declared const, but this ing outside of a valid object. This case refers to pointer
guarantee is very hard to make statically and the removal arithmetic where the end result is within the bounds of an
can violate programmer intent. object, but intermediate results are not. This is undefined
behavior according to the C specification and makes even
We would like to be able to make a const pointer a
conservative garbage collection impossible unless a valid
guarantee that nothing that receives the pointer may write
pointer to the object is guaranteed to also exist.
to the resulting memory. This allows const pointers to be
passed across security-domain boundaries. Without this being expected to work, we could trap as
soon as a pointer went out of range, rather than waiting
Container describes behavior in a macro common in the until it is dereferenced. This would be useful mostly as a
Linux, BSD, and Windows kernels that, given a pointer
to a structure member, returns a pointer to the enclosing
 debugging aid, as there are no extra security or reliability The relatively large number of instances of pointer sub-
guarantees from preventing these operations. traction in C code that we observed (Table 1) supports our
Int refers to storing a pointer in an integer variable in anecdotal observation that the lack of this support in the orig-
memory—implementation-defined behavior in C. We ig- inal C implementation for CHERI (described in detail in the
nore variables where the store-load sequence is opti- next section) would be problematic. We have not been able
mized away in calculating these. Disallowing this behav- to find the Last Word pattern by static analysis and thus have
ior makes accurate garbage collection possible, as the not included it. Note that most of the cases of invalid inter-
compiler can statically track every pointer use. It also mediates also involve subtraction; we have predominantly
eliminates a category of error where a value is manip- classified instances as subtraction if the pointers are deref-
ulated as an integer and later interpreted as a pointer. erenced immediately after the subtraction, indicating either
that the code is buggy or the pointer is valid.
IA refers to performing integer arithmetic on pointers— Arbitrary arithmetic on integers that are then cast to
such as storing a pointer in an integer value and then pointers is rare. The majority of the occurrences that we have
performing arbitrary arithmetic on it. This is a more seen are in the malloc() implementation in FreeBSD libc
general case of the Int idiom and relies on the same (jemalloc [13]). This is difficult to avoid, as malloc() is
implementation-defined behavior. It also makes conser- outside of the C abstract machine. The C specification indi-
vative garbage collection impossible, as the garbage col- cates that each block of memory returned by malloc() is an
lector can assume that every integer may be a pointer and object and that it is undefined behavior to use it after calling
still do a reasonable job, but cannot do any collection if free(). This means that, with a strict interpretation of the
pointers can be easily hidden. specification, it is impossible for the code inside free() to
Mask refers to simple masking of pointers. For example, recycle the memory. Similarly, the memory that has not yet
to store some other data in the low bits. This relies on been returned by malloc() is not yet part of the C abstract
pointers having a known representation. Breaking this al- machine. In real implementations, the compiler makes suffi-
lows more efficient pointer representations, for example cient allowances to permit these functions to be implemented
the “low-fat pointers” [18] representation for fat pointers. in C atop some more primitive functionality (mmap() or brk
Wide refers to storing a pointer in an integer variable of a (), which deals with pages of memory.
smaller size. This is undefined according to the C spec- We investigate tcpdump more closely in §5.2, where we
ification, but may work if you are able to guarantee that discuss porting it to two CHERI variants. It is worth noting
pointers are within a certain range, for example by allo- that numerous cases of invalid intermediates involve bounds-
cating memory with malloc and the MAP_32BIT flag. checking code: These are not required at all if the underly-
ing implementation supports bounds checking. We therefore
Code using this idiom is broken by existing implementa-
observe that, for at least some code, modifications to allow
tions, and most likely reflects bugs in the code. We were
compatibility with a restricted memory-safe implementation
surprised to see examples of this in programs that we
of C would simplify the code.
inspected, but fortunately it is sufficiently rare that fix-
ing all of the cases would be easy in these codebases.
This idiom is the result of assuming that sizeof(int) 3. The C abstract machine
== sizeof(void*) or sizeof(int32_t)== sizeof
Having identified a set of idioms that an implementation
(void*). This assumption was true for desktop comput-
must support, we now look at the requirements imposed
ers for a long time, and mobile devices until recently.
by the language. It is possible to implement the C abstract
Had we run the same experiment 15 years ago, we ex-
machine for any Turing-complete target, but that does not
pect we would have seen many more instances of this
mean it is easy or efficient to do so. When considering a low-
assumption. We conclude that C codebases adapt (over
level language like C, there are three important requirements
time) to changes in pointer behavior, and that additional
on a compilation target:
small changes are not impossible to support.
Last Word refers to accessing an object as aligned words Expressiveness: It must be sufficiently expressive to cap-
without regard for the fact that the object’s extent may ture the semantics of the abstract machine.
not include all of the last word. This is used as an op-
Efficiency: The primitive operations in the abstract machine
timization for strlen() in FreeBSD libc. While this is
must map simply to primitive operations in the underly-
undefined behavior in C, it works in systems with page-
ing system, allowing low-overhead implementation.
based memory protection mechanisms, but not in CHERI
where objects have byte granularity. We have found this Exposure: The features of the underlying system must be
idiom only in FreeBSD’s libc, as reported by valgrind. exposed to the programmer. For example, the language
should expose the register types of the underlying archi-
tecture as primitive types.
 A language can be described as low level with regard to arithmetic operation to be followed by a branch-on-carry
a particular platform only if it meets these requirements. It with a trap instruction (ud2 on x86) at the destination. The
must be possible to compile the language to run on the target clang variant also permits a handler function to recover from
system, but also to do so without introducing significant the overflow. This was used to implement a prototype of
abstraction layers that hinder performance or hide the details the As-if Infinitely Ranged (AIR) proposal by CERT [11].
of the underlying architecture. Similar work was done later by MIT’s KINT [31] system,
This section discusses the flexibility that the C abstract defining an integer equivalent of the not-a-number (NaN)
machine allows implementers, both with respect to the prim- values found in floating point systems. These efforts have all
itive types used for memory access (integers and pointers), been purely focused on the compiler, and not on extending
and the layout and semantics of memory itself. We take par- the underlying architecture.
ticular note of changes that can be made to enforce mem-
ory safety without compromising the low-level nature of C. 3.1.2 Pointers
The C abstract machine does not include an idea of address In BCPL [24], an ancestor of C, pointers and integers were
translation—intentionally, as not all targets have MMUs— both words: pointers were words that could be derefer-
so, from the perspective of userspace C programs running on enced. In contrast, C was intended to support minicomputer
an operating system, we always mean virtual memory when and mainframe architectures, including segmented memory
we refer to memory as described by the abstract machine. models and microcontrollers with separate integer and ad-
dress registers. The PDP-11 model of C follows closely from
3.1 Primitive types BCPL: pointers are integers, any pointer can be cast to any
The C specification is intentionally vague on the representa- sufficiently large integer type, and results of casting can be
tion of most primitive types, allowing significant variety. used as pointers. Pointer arithmetic is just integer arithmetic.
This behavior is not mandated by the C standard. The
3.1.1 Ranges and representations
abstract machine divides memory into objects: regions of
Before we can consider modifying how pointers are im- memory with an associated type. Pointer arithmetic that ends
plemented in C, we should examine the requirements that outside of the original object is undefined, with the exception
the specification places on the implementations of primi- that pointers may point one element past the end of arrays,
tive types. §5.2.4.2.1 [16] is devoted to the ranges of integer but such a pointer is valid only for comparison, not for deref-
types. It defines a minimum range that each can represent. erencing. §7.20.1.4 [16] defines an optional intptr_t as an
Implementations may support larger ranges, with the excep- integer type that can store a pointer and have the pointer
tion of the char type. C11 requires it to be at least 8 bits, value preserved. There is no guarantee that any arithmetic
but POSIX requires that it is exactly 8 bits, providing a con- on intptr_t will result in a valid pointer and dereferencing
crete practical limit for implementations wishing to run code any such pointer is implementation defined. Pointer compar-
designed for any UNIX-like system. isons between pointers to different objects are undefined, al-
Within this size, the only constraint is that a signed char lowing the implementation to move objects as long as it does
must be able to represent integers between -127 and 127. so atomically with respect to the running code.
Most modern machines opt to use two’s complement arith-
metic, as it simplifies many operations. Two’s complement 3.1.3 The null pointer
representation allows values from -128 to 127 to be repre- As per §6.3.2.3 [16], the integer value 0 has a special mean-
sented. This leaves one value that can be represented, but ing when cast to a pointer: It must be distinct from any valid
which is outside of the range required by the specification. object in the system. This value is relevant (according to the
Most arithmetic operations can overflow. The §6.2.5 [16] specification) only when it is an integer constant expression
defines that overflow of unsigned values should wrap. that evaluates to 0. This distinction is important. For exam-
Signed overflow is undefined and may produce a trap rep- ple, the specification does not require that the following be a
resentation: A value that may trap if used and whose use null pointer:
makes any subsequent behavior undefined.
int i = 0; void * p = ( void *) i ;
These two facts lead to a potential implementation that
allows cheap trapping on overflow in hardware. All signed This distinction is difficult to support in modern compil-
arithmetic that overflowed would be set to this trap value, ers, as discussed in a recent LLVM mailing list thread [1].
and all signed arithmetic operations that took this value and
an input would raise an exception. This would necessitate 3.2 State of the unions
different instructions for signed and unsigned addition, but Footnote 95 in §6.5.2.3 [16] contains the exception to the
there is some precedent for this. MIPS, for example, includes normal aliasing rules:
operations that differ only by whether they trap on overflow. If the member used to read the contents of a union object is
Trapping on signed overflow is not a new idea. Both clang not the same as the member last used to store a value in the
and gcc provide a -ftrapv flag that causes every signed object, the appropriate part of the object representation of
the value is reinterpreted as an object representation in the C. This idiom is now very uncommon, due to its poor inter-
new type...This might be a trap representation. action with pipelined processors.
This requirement is one of the things that makes C useful Relying on the alignment to identify unused bits in a
in low-level contexts: It is possible to subvert the type system pointer is more common. On a 64-bit platform, most values
and interpret memory as different forms. Supporting unions are 8-byte aligned, and so the low 3 bits in a pointer are
can be difficult in environments with guarantees about type zero. It is therefore safe for a program to store information
safety but is important for our exposure requirement. in these bits. The ARMv8 architecture [3] extends this with
a mode guaranteeing that the MMU will not use the top 8
3.3 Code and data memory bits in a virtual address when performing address translation,
C is intended to be usable on microcontrollers with separate allowing them to be used for storing program-specific data.
address spaces for code and data. A numerical pointer value
may be different when interpreted as referring to data and 3.6 Garbage hoarding
code. In particular, a void* may refer to any kind of data, To add full memory safety to C would require temporal as
but is not guaranteed to be able to represent function point- well as spatial safety. We can add spatial safety within the
ers. POSIX breaks this separation by introducing the void confines of the abstract machine by changing the represen-
*dlsym(. . . ) function, used to look up a symbol in a shared tation of pointers to include bounds. Efficiently adding tem-
library. This is beyond the scope of the C language specifi- poral safety is more difficult.
cation, which has no notion of shared libraries, but is very Existing conservative garbage collectors for C, such as
important, e.g., for finding plugin interfaces. Unfortunately, the Boehm-Demers-Weiser collector [5], fail in cases out-
looking up function pointers is a common use for dlsym, lined in §3.5 because they make assumptions about pointer
and is not defined behavior in C. representations. The ability to recover pointers from integers
arithmetic makes accurate garbage collection impossible be-
3.4 Const enforcement cause any integer value may potentially be combined with
The const qualifier indicates that a pointer should not be others to form a valid address.
used to write memory. In typical C implementations, the im- It is not possible to implement a copying or relocating
mutability of const-qualified objects varies. Literal strings garbage collector if it is possible for object addresses to es-
are mapped read-only into the running process. Attempting cape from the collector. The conservative garbage collectors
to modify one will cause a segmentation fault. It is there- that are possible allow garbage objects to be accidentally
fore safe to remove a const qualifier only if you know ex- hoarded by integers that contain valid addresses.
actly where it was inserted. Unfortunately, the C specifica- We believe that efficient implementations of full temporal
tion contains functions such as memchr, which takes a const safety will require C implementations that are valid within
-qualified pointer as the first argument, and returns a (non- the requirements of the C abstract machine, but have unex-
const) pointer derived from it, stripping the const qualifier. pected behavior for much existing code. It is undefined be-
This function signature exists because the C type system havior in C to compare two pointers to different addresses
cannot express the real requirement: that the function has but in spite of this it is common to use addresses for compar-
a contract not to modify the buffer, and that the mutability ison in trees or as input to hashes for hash tables. This works
associated with the returned pointer should be equal to the in current implementations but would break if a collector is
rights that the caller has to the first argument. allowed to modify addresses.

3.5 Pointer provenance 4. Refining the CHERI model

The C specification makes the ability to store pointers in in- Our CHERI processor provides a fine-grained memory pro-
teger variables and then recreate the original pointer imple- tection model via memory capabilities, which are hardware-
mentation defined, but many software packages in practice enforced unforgeable references to regions of memory. In
depend on this functionality. In common implementations, the CHERI world, all memory is accessed via a memory ca-
as long as the integer is derived from the initial pointer, and pability. The ISA is a superset of MIPS IV, an existing 64-bit
the result of arithmetic is within the bounds of the object, ISA, and can run unmodified MIPS code.
then arbitrary arithmetic is permitted. The notion of an inte- Version 2 of the CHERI ISA [35] was created based on
ger derived from a pointer is somewhat vague. initial experiences attempting to build a capability system
The xor linked list is a simple example where this is prob- that was a usable compiler target for C. For example, this
lematic. Each node has a pointer that is the address of the change propagated tag bits into capability tag bits, rather
previous node xor’d with the address of the next node, al- than preventing memory without tag bits from being loaded
lowing traversal in both directions. The pointer is derived into capability registers. This was motivated by the need for
from the addresses of both objects. This is particularly chal- memcpy() (which is called explicitly by the user and implic-
lenging when attempting to produce a formal semantics of itly by the compiler) to be able to copy data without being
aware of whether it contained pointers. A similar require- tion of the base field is not required. Ideally, however, the
ment applies to unions. compiler would be able to automatically employ capabili-
CHERIv2 memory capabilities are represented as the ties for all pointers, subject to binary-compatibility concerns
triplet (base, bound, permissions), which is loosely packed with capability-unaware code, which requires more broad
into a 256-bit value. Here base provides an offset into a vir- support for arbitrary pointer arithmetic. We found, for ex-
tual address region, and bound limits the size of the region ample, that real-world code such as tcpdump (see §5.2) un-
accessed; for CHERIv2 they are each 64-bits in length. For dertakes pointer arithmetic which, during intermediate steps,
a discussion of permissions, see [33]. Capabilities reside ei- goes beyond the bounds of the structure the pointer is sup-
ther in a dedicated register file or can be spilled to mem- posed to be referencing, but which (usually) ends up within
ory, where their integrity is preserved by hardware-managed the bounds during a memory access. To make CHERI-style
tagged memory. Capabilities must be naturally aligned and capabilities better fit the C-based pointer idiom, and allow
there is a single tag bit per 256 bits of memory. Conven- automated use with unqualified pointers, we have therefore
tional stores to an in-memory capability cause the tag bit extended the memory capabilities found in CHERIv2 with
to be cleared, invalidating the capability. Special capability the attributes of fat pointers, to produce the CHERIv3 ISA.
load and store instructions allow capabilities to be spilled Our fat-capabilities add an offset to the CHERIv2 capability
to the stack or stored in data structures, just like pointers. model to form: (base, bound, offset, permissions).
CHERIv2 supports use of capabilities as C pointers, with The general idea of a fat pointer is well explored and
the caveat that pointer subtraction is not allowed. their benefits in providing spatial memory safety are well
Memory accesses are indirected via capabilities in three documented: pointers are supplemented by base and bounds
ways. Instruction fetches are relative to the program counter values that, on dereference, throw a trap if an inappropri-
capability (PCC). Legacy MIPS loads and stores are rela- ate access is requested. CHERIv3 fat-capabilities have two
tive to the default data capability. Finally, the CHERI ISA advantages over conventional fat pointers: (1) fat-capability
provides a set of load and store instructions that take an ex- integrity and non-decreasing rights are guaranteed by the
plicit capability register operand. The only instructions that hardware capability model while still supporting arbitrary
modify a capability strictly reduce its permissions, either by pointer arithmetic; and (2) the permissions field permits ad-
increasing the base (and decreasing the length by the same ditional hardware-checked constraints to be imposed, poten-
amount), decreasing the length, or reducing the permissions. tially for garbage collection or information-flow labeling.
When a process starts, it has a default data capability that Integrity is especially important in the presence of concur-
covers the entire user address space. This can be partitioned rency: a thread-safe fat pointer implementation must guar-
and restricted, for example by limiting its use to the mem- antee that the entire fat pointer is updated atomically.
ory allocator, and referring to other memory purely via ca- These distinctions allow memory capabilities to be used
pabilities returned from the allocator, the linker, or from the as building blocks for higher-level security features. The
stack capability. It is the responsibility of the allocator (or total memory that is reachable from a piece of code is the
the compiler, for stack allocations) to correctly set the length transitive closure of the memory capabilities reachable from
on capabilities. Once set, it is impossible to use the resulting its capability registers, making it possible for some threads
capability to gain access to memory outside the object. (for example) to have limited rights to memory within a
Code compiled for our extension to the CHERI ISAv2 program. The addition of permissions allows capabilities to
runs atop the FreeBSD operating system on a modified be tokens granting certain rights to the referenced memory.
CHERI processor synthesized to run in FPGA at 100MHz. For example, a memory capability may have permissions
Our goal is to demonstrate that it is possible to meet all of to read data and capabilities, but not to write them (or just
our requirements for a low-level language compilation target to write data but not capabilities). Attempting any of the
from an instruction set that provides spatial memory safety. operations that is not permitted will cause a trap.
In particular, all of the mechanisms provided by the hard- This allows memory capabilities to enforce the const
ware can be exposed to a C programmer directly, and all of qualifier on pointers, by removing the store permission. We
the aspects of memory behavior defined by the abstract ma- did implement support for this in the original C compiler for
chine are translated into simple machine instructions without CHERIv2, but found that it broke a large amount of code.
any complex abstraction layers or support libraries. We subsequently added __input and __output qualifiers
that make it possible to declaratively discard write and read
4.1 Converging capabilities and fat pointers
permissions, respectively.
CHERI ISAv2 capabilities provide C-like pointer semantics It is possible in the CHERIv2 model to implement fat
subject to non-increasing rights imposed by the capability pointers as a pair of a capability and an (integer) offset. This
model. The CHERI ISAv2 compiler allows code authors to has several disadvantages. The first is the size. CHERIv2
qualify suitable pointers for compilation using capabilities, capabilities are already 256 bits and must be aligned. The
implicitly confirming that any manipulation of the pointer alignment requirement would mean that an array of fat point-
is compatible with those restricted rights; e.g., that subtrac-
 I NSTRUCTION U SE As bounds information is not carried by traditional point-
ers, these instructions must be used carefully and are relevant
CIncOffset Adds an integer to the offset only in a hybrid environment, where the memory-safe capa-
CSetOffset Sets the offset bility view and the traditional view of pointers are mixed.
CGetOffset Returns the current offset As our canonical null capability is untagged, it can never be-
CPtrCmp Compares two capabilities come a valid capability. Arithmetic may alter the offset of
CFromPtr Converts a MIPS pointer to a capability the NULL capability allowing constructions such as return-
CToPtr Converts capability to a MIPS pointer ing -1 from mmap() to indicate failure.
As long as the appropriate modifications are made for
Table 2. New CHERI instructions to better support C each instance of its use, with CHERIv3, a __capability
-qualified pointer can be used anywhere (library interfaces
permitting) that a traditional pointer can. When a capability-
ers represented this way would use 64 bytes per pointer, al- qualified pointer is used in a union and then modified as a
though 24 of those would be padding. This approach would non-capability type, the result is an invalid capability that
also make atomic updates to pointers difficult. Updating a will trap when used for memory access. This is provided by
pointer in memory requires writing the capability and the in- CHERI’s tagged memory, which clears the is-a-capability
teger value atomically, which is not something that is easy to tag bit associated with the memory when a non-capability
add with current DRAM memory widths. operation is used to store to a given address.
To access this new offset, we added the instructions de- CHERIv3 C supports storing data in unused bits of a
scribed in Table 2. In addition to these extra instructions, we pointer as the pointer can point anywhere in the virtual ad-
modified CIncBase to update the pointer such that the offset dress space (but must be within the bounds before it can be
remained constant and modified all of the load and store op- used). These programmer optimizations rely on the knowl-
erations to use the pointer value. Our total changes amount edge of implementation-defined behavior (such as the align-
to 496 lines of changes to the Bluespec source for the proces- ment of types and representation of pointers) to be efficient.
sor and 218 lines of changes to the test suite. These changes As such, we consider it sufficient that they work, without
did not alter the critical path of the pipeline—the virtual ad- requiring that they be efficient.
dress calculation for loads and stores—which is now done by With CHERIv3, it is possible to use a code capability for
adding the offset to the pointer, rather than to the base. It did every function. Each function invocation becomes a capa-
add a small amount of complexity to the bounds checking bility jump-and-link-register (CJALR) instruction, which re-
logic. This now checks the resulting address against the base places the PCC with a new capability register, the PC with a
and top, rather than just against the length, so this pipeline new register, and saves the old ones. This means that when
stage (which happens in parallel with the cache fetch) is ex- a function is executing, it is impossible to jump out of it
tended in length by one OR operation. without an explicit call. Unfortunately, implementing this in
To avoid accidentally leaking virtual addresses into inte- practice is somewhat difficult as compilers and linkers make
ger registers, we added a CPtrCmp instruction that compares assumptions about their ability to place constants close to
the base plus offset of two capabilities as if they were point- functions and depend on the program counter address to lo-
ers. This instruction orders all tagged capabilities after all cate globals. Resolving this would require a completely new
untagged capabilities. Integer values stored in a capability ABI, which is the subject of ongoing work.
are constructed by setting the offset of the canonical null ca- We have implemented a relocating generational garbage
pability and will never compare equal to any valid capability. collector for CHERIv3 that uses the tagged memory to dif-
ferentiate between capabilities and other data. Determining
4.2 Interoperability
how much software will be broken by this is ongoing work.
We added two instructions, CToPtr and CFromPtr, to con-
vert between a capability and a traditional pointer. These 5. Evaluation
take three operands, the capability and integer registers as
To evaluate our approach, we consider two questions:
the input and output, and a base capability that indicates the
capability to which linear pointers are relative. • To what extent does compilation of the current C-
The CFromPtr instruction allows a pointer to be derived language corpus depend on C idioms specific to PDP-
from the default data capability. It has special case behavior 11-like concrete implementations?
of giving a canonical null capability (all zeros with the tag • How do alternative memory models function with respect
bit cleared) if the offset within the default capability is 0, to
to correctness and performance of C applications?
adhere to C’s null pointer semantics. CToPtr provides the
address of the capability as an offset from a base capability We explored the first question earlier, discovering a set of
(so that it can be used as a pointer relative to the default data common idioms, and extracting simple test cases for each of
capability) or 0 if this value would be out of range. them. Having identified these cases, we explored which of
them will function with different interpretations of the stan- arbitrary arithmetic is allowed only in places where doing so
dard. In addition to the x86 and MIPS baselines, the orig- would not damage the memory-safety model.
inal CHERIv2 implementation, and our CHERIv3 variant, The Strict model is close to our ideal interpretation of
we implemented a translator for C code into a simple ab- the C standard, disallowing a large set of operations that
stract machine interpreter. This runs very slowly but allows are potentially dangerous. Unfortunately, Strict also breaks
us to quickly modify the abstract machine and run the test many assumptions in existing code. Given the amount of
cases extracted from the idioms to see which fail. time taken to ensure that the majority of C code is 64-bit
For the second question, we evaluated the two CHERI clean, it is important to provide incremental steps to improve
C implementations against the same code compiled using C code. The CHERIv3 target is attainable in the short term
the MIPS ABI. For this part of the evaluation, we added with small amounts of work, from which it will be easier to
__capability qualifiers to pointers in the application, but refine code to operate in an environment where pointers are
retained the non-memory-safe versions for external pointers strictly distinct from integers.
– for example, for use with system library routines. Intel’s MPX and HardBound both rely on explicit instruc-
tions to tag pointer bounds. This approach relies on the com-
5.1 Comparing implementation models piler being able to determine that it is operating on a pointer.
These results are shown in Table 3. They contrast traditional Casting a pointer to an integer and then performing arbitrary
PDP-11-like x86 and MIPS implementations with the fol- arithmetic prevents the compiler from asserting the bounds.
lowing other possibilities: These two models (neither is yet available as an implemen-
tation, although Intel provides an MPX simulator) provide
HardBound refers to the model as described in [12]. subtly different tradeoffs. The Intel version leans more in the
direction of compatibility. If a pointer is modified in such
Intel MPX refers to the bounds-checking extensions to x86
a way that the MPX extensions are not updated, then the
proposed by Intel. value will fail its check against the copy of the pointer in the
Relaxed interpreter allows pointers to be constructed from look-aside table that the CPU uses to maintain the pointer
integer values as long as the object is still valid. The top state. If this occurs, then the bounds checks succeed uncon-
32 bits of the pointer are used to look up a valid object in ditionally. This preserves compatibility, but at the expense of
a map and the low 32 bits describe an offset. safety. In contrast, HardBound does not store the pointer in
Strict interpreter allows pointers to be reconstructed from the look-aside table and so will assume the old bounds, even
integers if (and only if) they are not modified in their if the pointer now refers to a different object and so will fail
integer representation. closed, preferring a detectable error to compatibility. Both
have integer arithmetic on pointers and masking marked as
CHERIv2 describes the original C compiler for CHERI,
not working, although this does depend on whether the com-
without offset support, where pointer addition decreases
piler is able to correctly propagate the bounds.
the range of the underlying capability.
In our simple test cases, MPX failed the Container check
CHERIv3 describes a new version of the CHERI ISA that because the compiler associated bounds with the inner
allows capabilities to act as fat pointers. pointer and so hit a bounds check. Our test cases passed
for MPX with arbitrary arithmetic and masking, but this de-
The MIPS and x86 abstract machines do not differ in pends on the compiler updating the bounds correctly. This
ways relevant to our analysis. is more difficult in programs where the compiler cannot see
Several of the results in this table require additional ex- that a particular integer contains a pointer value.
planation. Both CHERI implementations allow storing ca- MPX also suffers significant problems with atomicity. Its
pabilities in integers of type intcap_t, but not in normal metadata is stored in look-aside tables, in separate pages
C integers. The CHERIv3 implementation performs arith- to the relevant data. This leads to race conditions in multi-
metic on these using the offset, and so does permit arbitrary threaded environments, as both locations must be changed in
arithmetic. The original CHERI implementation permitted response to pointer modifications. As MPX relies on explic-
only storing and loading of these values. The Strict imple- itly updating pointer metadata, it is also difficult to imple-
mentation has the same restriction: pointers can be stored in ment memcpy and similar functions, which must copy mem-
integers, but any arithmetic will invalidate the pointers. ory without being aware of the types of its contents.
These provide five points on a continuum trading safety The “best effort” translation of integers to pointers in the
for compatibility. CHERIv3 supports all of the idioms that Relaxed model allows accidental construction of valid, but
we identified as being important to avoid breaking for com- incorrect, pointers. This cannot happen with the CHERI ver-
patibility with existing code. We address the const enforce- sion, as unsafe arithmetic would invalidate the capability,
ment issue by making const advisory and providing a new and provides an interesting alternative similar to some at-
qualifier (__input) that is hardware enforced. There is also tempts at adding bounds checking to C code; it gives little
the caveat that storing pointers in integers and performing
 P ROGRAM D ECONST C ONTAINER S UB II I NT IA M ASK W IDE
x86/MIPS/PDP-11 yes yes yes yes yes yes yes no
HardBound yes yes yes yes (yes) no no no
Intel MPX yes no yes yes (yes) (yes) (yes) no
Relaxed yes yes yes yes yes yes yes no
Strict yes yes yes yes (yes) no no no
CHERIv2 no no no no (yes) no no no
CHERIv3 yes yes yes yes (yes) yes yes no

Table 3. Summary of idioms supported by different interpretations of the C abstract machine.

benefit in terms of source compatibility, compared to the ca-

Time difference (%)

CHERI
pability version, in exchange for a weaker memory model. 30
CHERI (copying)
All of our original set of requirements for an implemen- 20
tation of a low-level language, meet the expressiveness re-
quirement, according to the specification—except for the 10
original CHERI implementation. The lack of pointer sub- 0
traction means that the implementation did not meet the 212 213 214 215 216 217 218 219 220 221
requirements of the abstract machine. More interesting is File size (bytes)
whether it captures the semantics expected by programmers.
From Table 1, we observe that most C code can function with Figure 4. Overhead of CHERI-zlib normalized against zlib
the restrictions imposed by CHERI. The relaxed restrictions compiled for a conventional MIPS ISA.
in our modified CHERI will still break code that expects to
be able to remove a const qualifier, but the only other mod- relative to the CPU speed, so cache misses are more common
ification required is changing the intptr_t typedef to re- but less costly than on most modern processors.
fer to the intcap_t type and ensuring that this type is used The first column shows the lines whose only changes are
whenever pointers are stored in integer values. to mark pointers as capabilities. We made these changes
CHERIv2 and CHERIv3 score very highly on efficiency. manually to understand their placement, but the compiler
Each C operation is a short sequence of machine instruc- can now use capabilities to represent all pointers. The im-
tions. Loads and stores are single instructions, and address portant numbers are the semantic changes required because
calculations are either register or immediate offsets, or the of the different memory models.
result of a CSetOffset or CIncOffset instruction. Having ported the code, we benchmarked it with unmodi-
The exposure requirement is a bit more difficult to judge fied MIPS code and CHERIv3. The Olden benchmarks were
objectively. For the CHERI implementation, all of the func- run with the parameters in the CHERI ISCA paper [35]. The
tionality of the underlying substrate is exposed, and the prop- Olden results are shown in Figure 1. The Dhrystone bench-
erties of a capability (length, permissions, and so on) can be mark was run for 500,000 iterations on each run and the re-
queried via intrinsics. sults are shown in Figure 2. Finally, the performance of tcp-
dump was measured by processing the first 100,000 packets
5.2 Whole program testing from the A.pcap061106170025.pcap file from a network
Having demonstrated that our modified CHERI ought to trace from OSDI 2006[6] is shown in in Figure 3.
be able to implement almost all of the requirements of C The slowdown for tcpdump (unmodified MIPS vs.
code, we next attempt to validate that assumption by porting CHERIv3) was 4%±3%. For comparison, small changes to
a small selection of programs to run on it. We used the optimizations in our LLVM gave a 15% speedup for tcp-
Olden benchmark suite (which is heavy in pointer use and dump, so 4% is well within the margin for errors. Changes
so demonstrates a worst case for CHERI), Dhrystone (a less in cache and TLB pressure resulting from small changes to
pointer-intensive benchmark), tcpdump (as an illustrative code layout can be larger. The Dhrystone results show the
application), and zlib (as an illustrative library). CHERI version to be around 2% faster than the MIPS code,
Table 4 shows the number of lines of code and percentage but this is well within the margin of error simply for changes
of the total changed to adapt each to run on CHERIv2 and to instruction cache usage. These results lead us to believe
CHERIv3. All of these results are for CHERI synthesized to that strong memory protection need not incur a statistically
run at 100MHz on a Stratix IV FPGA. The L1 data cache significant slowdown. The T-test places the difference in per-
is 16KB and the L2 cache is 64KB. This is smaller than formance at 95% confidence below the experimental varia-
most contemporary processors, but the DDR DRAM is faster tion from small changes to compiler performance.
 CHERI V 2 CHERI V 3
P ROGRAM Baseline LoC Annotation Semantic Total Annotation Semantic Total
Olden 1519 53 (3.5%) 0 (0%) 53 (3.5%) 53 (3.5%) 0 (0%) 53 (3.5%)
Dhrystone 448 11 (2.4%) 0 (0%) 11 (2.4%) 11 (2.4%) 0 (0%) 11 (2.4%)
tcpdump 66555 3006 (4.5%) 1,577 (2.4%) 4583 (6.9%) 3006 (4.5%) 2 (0.0%) 3008 (4.5%)

Table 4. Lines of code changed to port from MIPS to CHERIv2 and CHERIv3

MIPS Smaller is better Bigger is better Smaller is better

Dhrystones (per-second)
30,000
100 CHERIv2

Time (seconds)
Time (seconds)

CHERIv3 100
20,000

50
10,000 50

0 0 0
ort MS
T
eadd ter
MI
PS Iv2 Iv3 MI
PS Iv2 Iv3
Bis Tre erim
e
HE
R
HE
R ER ER
P C C CH CH

Figure 1. Olden results Figure 2. Dhrystone results Figure 3. Tcpdump results

The effort required to port C code to a memory-safe envi- crash tcpdump (if not execute arbitrary code) to blind oppo-
ronment depends significantly on the coding style employed. nents is a common strategy in capture the flag uompetitions.
We have observed that the code that could most benefit from The code would benefit substantially from strong memory
a memory-safe substrate (judging from published vulnera- safety, yet written in a style that makes this very difficult.
bilities related to memory errors) is also the code that is Porting tcpdump to CHERIv2 required changes to around
harder to port. This observation is one of the motivations for 1.6K lines to avoid pointer subtraction: around 2.5% of the
allowing unmodified MIPS code in our CHERI implementa- total codebase. CHERIv3 is fully able to support the parts of
tion: it allows us to apply coarse-grained sandboxing to such the C standard expected by these codebases. Only, two lines
code. This means that even if we have to use non memory- of code had to be changed in just one file, to ensure that tcp-
safe code, the damage it can cause can be restricted. dump has read-only access to the packet being parsed rather
The two benchmark suites that we modified are both con- than the whole packet buffer. This change was not strictly
servative in their pointer use. They required changes only to required, but provided stronger and finer-grained protection
annotate some values with __capability, and performed than would otherwise be possible.
little or no unusual pointer arithmetic. In a pure capability We then modified the compiler to support a new ABI in
environment, no annotation would be required. This is fairly which all pointers are implemented as capabiliting, includ-
common in benchmark code. The performance difference ing references to on-stack objects, which are derived from
between them is primarily due to the larger pointers caus- a stack capability. We then compiled two versions of zlib
ing more cache misses. In spite of the relatively small cache using this mode. The first is entirely unmodified internally,
on CHERI (16KB L1, 64KB L2), this overhead is signifi- but requires some annotations in a header to allow it to be
cant only in the Olden benchmarks, which create and walk work with code using the MIPS ABI. This was limited to a
pointer-based data structures. Neither a CPU-focused bench- single pragma at the start and end of the library header, and
mark nor a real application showed significant slowdown. was required because zlib passes pointers across the library
The tcpdump codebase is very different from the bench- interface. This approach breaks binary compatibility for the
marks in terms of porting effort. Packet dissection involves library (though it retains source compatibility), so we also
substantial pointer arithmetic—ironically, frequently in ser- implemented a second version that preserves binary com-
vice of hand-crafted software bounds checking. Unfortu- patibility by copying structures whose layouts have changed
nately, tcpdump typically runs as root (to access raw packet whenever they are passed across the library boundary.
data from a network interface), and is often used for inspect- Figure 4 shows the results for compressing files of vary-
ing suspicious network traffic. This means that its packet ing sizes with the two modified and one unmodified version
parsers—written using extensive pointer arithmetic—are ex- of zlib, linked to the gzip program. Simply using capabili-
posed to malicious data. Crafting malicious packets that ties incurs no measurable overhead for large files and a small
overhead for small files (there is a small constant overhead to differentiate between fully GC’d memory and “pinned”
for setting up the capability environment). Copying data at pointers, which have stable integer values. With better hard-
the library boundaries to maintain binary compatibility in- ware support for protection, we argue that it becomes much
curs around a 21% overhead, independent of file size. easier to implement systems like these, with low-level code
running in the same environment to managed code.
6. Related work
Substantial prior work targets improving C memory safety. 7. Conclusion
Early examples include Cyclone [17], which explicitly broke Lack of memory safety in C leads to real and significant
compatibility with C to define a safer C dialect. Cyclone’s vulnerabilities, particularly as near-ubiquitous networking
abstraction is close to our model, but adds many static anno- for conventional computers and mobile devices has exposed
tations. Although Cyclone was not widely adopted, it influ- users to unprecedented malicious activity. This has reinvigo-
enced pointer annotation in current C compilers. rated interest in fine-grained memory protection to mitigate
The copious buffer overflow vulnerabilities in C code- exploit techniques. However, widespread assumptions about
bases have spurred development of a number of other pointer behavior, unwarranted by the C abstract machine but
bounds-checking systems. Research tools HardBound [12] consistent with the PDP-11 memory model, produce sub-
and SoftBound [22] add fine-grained bounds checking to stantial compatibility problems in real-world programs that
C, followed by commercial work, such as Intel’s Memory might most benefit from additional protection.
Protection Extensions [15]. None of these approaches han- To address these problems, we survey C-pointer idioms
dles some of the complex cases (for example, xor linked across a large open-source corpus to understand the effective
lists) outlined here, the key difference being that the Hard- consensus on pointer use that constrains memory-protection
Bound and SoftBound approaches will fail closed (prevent- schemes. We are then able to describe a range of points in
ing potentially dangerous memory accesses if the can’t track the protection and compatibility tradeoff space.
pointer provenance), whereas the Intel solution will fail open Observing potentially significant source-code compati-
(allowing unsafe access if the bounds can’t be determined). bility, we propose a new model, fully described and im-
Memory-related exploit techniques have spawned sub- plemented as the CHERIv3 ISA, that combines CHERI’s
stantial work in vulnerability scanning and dynamic mitiga- capability-system model with results from recent fat-pointer
tion [27]. Static analysis tools such as lint [14] and general research. Whole-program testing against conventional RISC,
bug pattern-matching tools [4] are effective for local anal- CHERIv2, and CHERIv3 illustrates significantly improved
yses, but are limited by weak type safety, global program source-code compatibility relative to a pure capability-
complexity, and difficult-to-analyze dynamic behaviors. Dy- system model, as well as modest performance improvement.
namic protections such as stack canaries and address-space These results confirm that it is possible to retain the strong
layout randomization offer probabilistic protection for spe- semantics of a capability-system memory model (which pro-
cific exploits [7], but suffer a constant escalation [29]. vides non-bypassable memory protection) without sacrific-
To run untrusted C code within a process that con- ing the advantages of a low-level language.
tains other data rights, SFI [30] and Google’s Native Client
(NaCl) [36] provide coarse-grained isolation for native code.
Similar techniques like Robusta [28] (and earlier work on Acknowledgments
process isolation [10]) isolate almost a million lines of C We thank our colleagues – especially Ross Anderson, Gre-
code libraries from JVM’s. Without isolation or a memory- gory Chadwick, Nirav Dave, Khilan Gudka, Steve Hand,
safe substrate, a single pointer error in the native code can Stephen Kell, Ben Laurie, Ilias Marinos, A Theodore Mar-
damage the entire VM, including the typesafe Java code. kettos, Ed Maste, Andrew W. Moore, Prashanth Mund-
SAFECode and SVA [8, 9] provide control flow integrity kur, Steven J. Murdoch, Robert Norton, Hassen Saidi, Pe-
and memory safety in TCB code, specifically in kernels, via ter Sewell, Stacey Son, and Bjoern Zeeb; we also thank our
compiler transforms. We believe that the run-time overhead anonymous reviewers for their feedback.
of these techniques would be lower with hardware assistance This work is part of the CTSRD and MRC2 projects that
described in this paper, and would provide powerful tools for are sponsored by the Defense Advanced Research Projects
quickly moving existing code to such a substrate. Agency (DARPA) and the Air Force Research Laboratory
Emscripten [37] is an interesting example of an unusual (AFRL), under contracts FA8750-10-C-0237 and FA8750-
deployment target for C, running C code in a JavaScript VM. 11-C-0249. The views, opinions, and/or findings contained
The runtime violates our exposure requirement by creating in this paper are those of the authors and should not be
the C heap in a single JavaScript object and not exposing the interpreted as representing the official views or policies,
JavaScript memory model. Microsoft’s various approaches either expressed or implied, of the Department of Defense or
to running C++ code in the .NET CLR [19] also provide the U.S. Government. We gratefully acknowledge Google,
some inspiration. These introduce different types of pointer Inc. for its sponsorship.
References introduction-to-intel-memory-protection-extensions,
[1] Is address space 1 reserved? URL http://lists.cs.uiuc. July 2013.
edu/pipermail/llvmdev/2015-January/080288.html. [16] ISO. ISO/IEC 9899:2011 Information technology —
Programming languages — C. International Organiza-
[2] Alelph One. Smashing the stack for fun and profit. Phrack
tion for Standardization, Geneva, Switzerland, Dec. 2011.
Magazine, 7:14–16, 1996.
URL http://www.iso.org/iso/iso_catalogue/
[3] ARM Architecture Reference Manual. ARMv8, for ARMv8- catalogue_tc/catalogue_detail.htm?csnumber=
A architecture profile. ARM Limited, 110 Fulbourn Road, 57853.
Cambridge, England CB1 9NJ, 2013.
[17] T. Jim, J. G. Morrisett, D. Grossman, M. W. Hicks, J. Cheney,
[4] A. Bessey, K. Block, B. Chelf, A. Chou, B. Fulton, S. Hallem, and Y. Wang. Cyclone: A safe dialect of C. In Proceedings
C. Henri-Gros, A. Kamsky, S. McPeak, and D. Engler. A few of the General Track of the Annual Conference on USENIX
billion lines of code later: Using static analysis to find bugs Annual Technical Conference, ATEC ’02, pages 275–288,
in the real world. Commun. ACM, 53(2):66–75, Feb. 2010. Berkeley, CA, USA, 2002. USENIX Association. ISBN 1-
ISSN 0001-0782. URL http://doi.acm.org/10.1145/ 880446-00-6. URL http://dl.acm.org/citation.cfm?
1646353.1646374. id=647057.713871.
[5] H.-J. Boehm and M. Weiser. Garbage collection in an unco- [18] A. Kwon, U. Dhawan, J. M. Smith, T. F. Knight, Jr., and
operative environment. Softw. Pract. Exper., 18(9):807–820, A. DeHon. Low-fat pointers: Compact encoding and efficient
Sept. 1988. ISSN 0038-0644. . URL http://dx.doi.org/ gate-level implementation of fat pointers for spatial safety
10.1002/spe.4380180902. and capability-based security. In Proceedings of the 2013
[6] R. Chandra, V. Padmanabhan, and M. Zhang. CRAWDAD ACM SIGSAC Conference on Computer and Communications
data set microsoft/osdi2006 (v. 2007-05-23). Downloaded Security, CCS ’13, pages 721–732, New York, NY, USA,
from http://crawdad.org/microsoft/osdi2006/, May 2007. 2013. ACM. ISBN 978-1-4503-2477-9. . URL http:
//doi.acm.org/10.1145/2508859.2516713.
[7] C. Cowan, P. Wagle, C. Pu, S. Beattie, and J. Walpole. Buffer
overflows: attacks and defenses for the vulnerability of the [19] Managed C++. Managed extensions for C++ specification.
decade. In DARPA Information Survivability Conference and http://msdn.microsoft.com/en-us/library/Aa712867 (accessed
Exposition, 2000. DISCEX ’00. Proceedings, volume 2, pages 2014/07/14).
119–129 vol.2, 2000. . [20] Microsoft Corporation. CONTAINING RECORD macro.
[8] J. Criswell, A. Lenharth, D. Dhurjati, and V. Adve. Secure URL http://msdn.microsoft.com/en-us/library/
virtual architecture: A safe execution environment for com- windows/hardware/ff542043%28v=vs.85%29.aspx.
modity operating systems. In SOSP ’07: Proceedings of the [21] Mitre. CWE/SANS top 25 most dangerous software errors,
Twenty First ACM Symposium on Operating Systems Princi- 2011. URL http://cwe.mitre.org/top25.
ples, October 2007. [22] S. Nagarakatte, J. Zhao, M. M. Martin, and S. Zdancewic.
[9] J. Criswell, N. Geoffray, and V. Adve. Memory safety for Softbound: Highly compatible and complete spatial memory
low-level software/hardware interactions. In Proceedings of safety for C. In Proceedings of the 2009 ACM SIGPLAN
the Eighteenth Usenix Security Symposium, August 2009. Conference on Programming Language Design and Imple-
mentation, PLDI ’09, pages 245–258, New York, NY, USA,
[10] G. Czajkowski, L. Daynes, and M. Wolczko. Automated and
2009. ACM. ISBN 978-1-60558-392-1. . URL http:
portable native code isolation. In Software Reliability Engi-
//doi.acm.org/10.1145/1542476.1542504.
neering, 2001. ISSRE 2001. Proceedings. 12th International
Symposium on, pages 298–307, Nov 2001. . [23] G. C. Necula, S. McPeak, and W. Weimer. Ccured: Type-
safe retrofitting of legacy code. In Proceedings of the 29th
[11] R. Dannenberg, W. Dormann, D. Keaton, R. Seacord, D. Svo-
ACM SIGPLAN-SIGACT Symposium on Principles of Pro-
boda, A. Volkovitsky, T. Wilson, and T. Plum. As-if infinitely
gramming Languages, POPL ’02, pages 128–139, New York,
ranged integer model. In Software Reliability Engineering (IS-
NY, USA, 2002. ACM. ISBN 1-58113-450-9. . URL
SRE), 2010 IEEE 21st International Symposium on, pages 91–
http://doi.acm.org/10.1145/503272.503286.
100, Nov 2010. .
[24] M. Richards. BCPL: A Tool for Compiler Writing and System
[12] J. Devietti, C. Blundell, M. M. K. Martin, and S. Zdancewic.
Programming. In Proceedings of the May 14-16, 1969, Spring
Hardbound: Architectural support for spatial safety of the C
Joint Computer Conference, AFIPS ’69 (Spring), pages 557–
programming language. SIGPLAN Not., 43(3):103–114, Mar.
566, New York, NY, USA, 1969. ACM. . URL http:
2008. ISSN 0362-1340. . URL http://doi.acm.org/10.
//doi.acm.org/10.1145/1476793.1476880.
1145/1353536.1346295.
[25] D. Ritchie, S. Johnson, M. Lesk, and B. Kernighan. UNIX
[13] J. Evans. A scalable concurrent malloc(3) implementation for
time-sharing system: The C programming language. Bell
FreeBSD. In BSDCan, 2006.
System Technical Journal, 57(6):1991–2019, July-Aug 1978.
[14] Gimpel Software. FlexeLint for C/C++, August 2014. URL [26] J. Saltzer and M. Schroeder. The protection of information
http://www.gimpel.com/html/flex.htm. in computer systems. Proceedings of the IEEE, 63(9):1278–
[15] Intel Plc. Introduction to Intel R memory protection exten- 1308, September 1975. URL http://www.multicians.
sions. http://software.intel.com/en-us/articles/ org.
[27] H. Shahriar and M. Zulkernine. Mitigating program security ion on Object Oriented Programming Systems Languages and
vulnerabilities: Approaches and challenges. ACM Comput. Applications Companion, SPLASH ’11, pages 301–312, New
Surv., 44(3):11:1–11:46, June 2012. ISSN 0360-0300. URL York, NY, USA, 2011. ACM. ISBN 978-1-4503-0942-4. .
http://doi.acm.org/10.1145/2187671.2187673. URL http://doi.acm.org/10.1145/2048147.2048224.
[28] M. Sun, G. Tan, J. Siefers, B. Zeng, and G. Morrisett. Bringing
Java’s wild native world under control. ACM Trans. Inf. Syst.
Secur., 16(3):9:1–9:28, Dec. 2013. ISSN 1094-9224. . URL
http://doi.acm.org/10.1145/2535505.
[29] L. Szekeres, M. Payer, T. Wei, and D. Song. Eternal war in
memory. In IEEE Symposium on Security and Privacy, 2013.
[30] R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham. Ef-
ficient software-based fault isolation. In SOSP ’93: Proceed-
ings of the fourteenth ACM Symposium on Operating Systems
Principles, pages 203–216, New York, NY, USA, 1993. ACM.
ISBN 0-89791-632-8.
[31] X. Wang, H. Chen, Z. Jia, N. Zeldovich, and M. F. Kaashoek.
Improving integer security for systems with KINT. In Pro-
ceedings of the 10th USENIX Conference on Operating Sys-
tems Design and Implementation, OSDI’12, pages 163–177,
Berkeley, CA, USA, 2012. USENIX Association. ISBN 978-
1-931971-96-6. URL http://dl.acm.org/citation.
cfm?id=2387880.2387897.
[32] X. Wang, N. Zeldovich, M. F. Kaashoek, and A. Solar-
Lezama. Towards optimization-safe systems: Analyzing the
impact of undefined behavior. In Proceedings of the Twenty-
Fourth ACM Symposium on Operating Systems Principles,
SOSP ’13, pages 260–275, New York, NY, USA, 2013. ACM.
ISBN 978-1-4503-2388-8. . URL http://doi.acm.org/
10.1145/2517349.2522728.
[33] R. N. Watson, P. G. Neumann, J. Woodruff, J. Anderson,
D. Chisnall, B. Davis, B. Laurie, S. W. Moore, S. J. Mur-
doch, and M. Roe. Capability Hardware Enhanced RISC In-
structions: CHERI Instruction-set architecture. Technical Re-
port UCAM-CL-TR-850, University of Cambridge, Computer
Laboratory, Apr. 2014. URL http://www.cl.cam.ac.uk/
techreports/UCAM-CL-TR-850.pdf.
[34] R. N. M. Watson, P. G. Neumann, J. Woodruff, J. Ander-
son, D. Chisnall, B. Davis, B. Laurie, S. W. Moore, S. J.
Murdoch, and M. Roe. Capability Hardware Enhanced
RISC Instructions: CHERI Instruction-set architecture. Tech-
nical Report UCAM-CL-TR-864, University of Cambridge,
Computer Laboratory, 15 JJ Thomson Avenue, Cambridge
CB3 0FD, United Kingdom, phone +44 1223 763500, Dec.
2014. URL http://www.cl.cam.ac.uk/techreports/
UCAM-CL-TR-864.pdf.
[35] J. Woodruff, R. N. M. Watson, D. Chisnall, S. W. Moore,
J. Anderson, B. Davis, B. Laurie, P. G. Neumann, R. Norton,
and M. Roe. The CHERI capability model: Revisiting RISC in
an age of risk. In Proceedings of the 41st International Sym-
posium on Computer Architecture (ISCA 2014), June 2014.
[36] B. Yee, D. Sehr, G. Dardyk, J. B. Chen, R. Muth, T. Ormandy,
S. Okasaka, N. Narula, and N. Fullagar. Native client: A
sandbox for portable, untrusted x86 native code. Commun.
ACM, 53(1):91–99, Jan. 2010. ISSN 0001-0782. . URL
http://doi.acm.org/10.1145/1629175.1629203.
[37] A. Zakai. Emscripten: An LLVM-to-JavaScript Compiler. In
Proceedings of the ACM International Conference Compan-