Capability Hardware Enhanced RISC Instructions: CHERI Instruction ...

Technical ReportNumber 850

Computer Laboratory

UCAM-CL-TR-850ISSN 1476-2986

Capability HardwareEnhanced RISC Instructions:

CHERI Instruction-set architecture

Robert N.M. Watson, Peter G. Neumann,Jonathan Woodruff, Jonathan Anderson,

David Chisnall, Brooks Davis, Ben Laurie,Simon W. Moore, Steven J. Murdoch,

Michael Roe

April 2014

15 JJ Thomson AvenueCambridge CB3 0FDUnited Kingdomphone +44 1223 763500

http://www.cl.cam.ac.uk/

c© 2014 Robert N.M. Watson, Peter G. Neumann,Jonathan Woodruff, Jonathan Anderson, David Chisnall,Brooks Davis, Ben Laurie, Simon W. Moore,Steven J. Murdoch, Michael Roe

Sponsored by the Defense Advanced Research ProjectsAgency (DARPA) and the Air Force Research Laboratory(AFRL), under contract FA8750-10-C-0237 (“CTSRD”) aspart of the DARPA CRASH research program. The views,opinions, and/or findings contained in this report are those ofthe authors and should not be interpreted as representing theofficial views or policies, either expressed or implied, of theDefense Advanced Research Projects Agency or theDepartment of Defense. Portions of this work weresponsored by the RCUK’s Horizon Digital EconomyResearch Hub grant, EP/G065802/1. Portions of this workwere sponsored by Google, Inc.

Technical reports published by the University of CambridgeComputer Laboratory are freely available via the Internet:

http://www.cl.cam.ac.uk/techreports/

ISSN 1476-2986

AbstractThis document describes the rapidly maturing design for the Capability Hardware EnhancedRISC Instructions (CHERI) Instruction-Set Architecture (ISA), which is being developed bySRI International and the University of Cambridge. The document is intended to captureour evolving architecture, as it is being refined, tested, and formally analyzed. We have nowreached 70% of the time for our research and development cycle.

CHERI is a hybrid capability-system architecture that combines new processor primitiveswith the commodity 64-bit RISC ISA enabling software to efficiently implement fine-grainedmemory protection and a hardware-software object-capability security model. These extensionssupport incrementally adoptable, high-performance, formally based, programmer-friendly un-derpinnings for fine-grained software decomposition and compartmentalization, motivated byand capable of enforcing the principle of least privilege. The CHERI system architecture pur-posefully addresses known performance and robustness gaps in commodity ISAs that hinderthe adoption of more secure programming models centered around the principle of least priv-ilege. To this end, CHERI blends traditional paged virtual memory with a per-address-spacecapability model that includes capability registers, capability instructions, and tagged memorythat have been added to the 64-bit MIPS ISA via a new capability coprocessor.

CHERI’s hybrid approach, inspired by the Capsicum security model, allows incrementaladoption of capability-oriented software design: software implementations that are more ro-bust and resilient can be deployed where they are most needed, while leaving less criticalsoftware largely unmodified, but nevertheless suitably constrained to be incapable of havingadverse effects. For example, are focusing conversion efforts on low-level TCB components ofthe system: separation kernels, hypervisors, operating system kernels, language runtimes, anduserspace TCBs such as web browsers. Likewise, we see early-use scenarios (such as data com-pression, image processing, and video processing) that relate to particularly high-risk softwarelibraries, which are concentrations of both complex and historically vulnerability-prone codecombined with untrustworthy data sources, while leaving containing applications unchanged.

This report describes the CHERI architecture and design, and provides reference documen-tation for the CHERI instruction-set architecture (ISA) and potential memory models, alongwith their requirements. It also documents our current thinking on integration of programminglanguages and operating systems. Our ongoing research includes two prototype processors em-ploying the CHERI ISA, each implemented as an FPGA soft core specified in the Bluespechardware description language (HDL), for which we have integrated the application of formalmethods to the Bluespec specifications and the hardware-software implementation.

3

AcknowledgmentsThe authors of this report thank other members of the CTSRD team, and our past and currentresearch collaborators at SRI and Cambridge:

Ross J. Anderson Gregory Chadwick Nirav Dave Brooks DavisKhilan Gudka Jong Hun Han Alex Horsman Alexandre JoannouAsif Khan Myron King Wojciech Koszek Patrick LincolnAnil Madhavapeddy Ilias Marinos A. Theodore Markettos Ed MasteAndrew Moore Will Morland Alan Mujumdar Prashanth MundkurRobert Norton Philip Paeps Colin Rothwell John RushbyHassen Saidi Hans Petter Selasky Muhammad Shahbaz Stacey SonRichard Uhler Philip Withnall Bjoern Zeeb

The CHERI team wishes thank its external oversight group for significant support and contri-butions:

Lee Badger Simon Cooper Rance DeLong Jeremy EpsteinVirgil Gligor Li Gong Mike Gordon Steven HandAndrew Herbert Warren A. Hunt Jr. Doug Maughan Greg MorrisettBrian Randell Kenneth F. Shotting Joe Stoy Tom Van VleckSamuel M. Weber

Finally, we are grateful to Howie Shrobe, MIT professor and past DARPA CRASH programmanager, who has offered both technical insight and support throughout this work. We are alsograteful to Robert Laddaga, who has succeeded Howie in overseeing the CRASH program.

4

Contents

1 Introduction 81.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.1.1 Trusted Computing Bases (TCBs) . . . . . . . . . . . . . . . . . . . . 111.1.2 The Compartmentalization Problem . . . . . . . . . . . . . . . . . . . 12

1.2 The CHERI Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.1 A Hybrid Capability-System Architecture . . . . . . . . . . . . . . . . 15

1.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Formal Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.5 CHERI and CHERI2 Reference Prototypes . . . . . . . . . . . . . . . . . . . 171.6 Historical Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6.1 Capability Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.6.2 Microkernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6.3 Language and Runtime Approaches . . . . . . . . . . . . . . . . . . . 221.6.4 Influences of Our Own Past Projects . . . . . . . . . . . . . . . . . . . 231.6.5 A Fresh Opportunity for Capabilities . . . . . . . . . . . . . . . . . . 24

1.7 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.8 Version History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.9 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2 CHERI Architecture 292.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2 A Hybrid Capability-System Architecture . . . . . . . . . . . . . . . . . . . . 312.3 The CHERI Software Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.4 Capability Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.4.1 Capabilities are for Compilers . . . . . . . . . . . . . . . . . . . . . . 342.4.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.3 Capability Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.4 Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.5 Ephemeral Capabilities and Revocation . . . . . . . . . . . . . . . . . 372.4.6 Notions of Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.7 Traps, Interrupts, and Exception Handling . . . . . . . . . . . . . . . . 382.4.8 Tagged Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.9 Capability Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 402.4.10 Object Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.4.11 Peripheral Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5

3 Capability Coprocessor 433.1 Capability Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.1 tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.2 u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.3 perms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.4 otype/eaddr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.5 base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.6 length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.7 Capability Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.3 Capability Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4 CPU Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.5 Changes to Standard MIPS Processing . . . . . . . . . . . . . . . . . . . . . . 523.6 Changes to the TLB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.7 Proposed Extensions to the CHERI ISA . . . . . . . . . . . . . . . . . . . . . 53

4 Instruction-Set Reference 554.1 Details of Individual Instructions . . . . . . . . . . . . . . . . . . . . . . . . . 55

CGetBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57CGetLen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58CGetTag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59CGetUnsealed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60CGetPerm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61CGetType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62CGetPCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63CGetCause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64CSetCause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65CIncBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66CSetLen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68CClearTag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69CAndPerm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70CSetType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71CCheckPerm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73CCheckType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74CFromPtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75CToPtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77CBTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79CBTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80CSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81CLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83CL[BHWD][U] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85CS[BHWD] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88CLLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91CSCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92CJR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93CJALR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6

CSealCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97CSealData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99CUnseal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101CCall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103CReturn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.2 Assembler Pseudo-Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.2.1 Capability Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.2.2 Get/Set Default Capability . . . . . . . . . . . . . . . . . . . . . . . . 1074.2.3 Capability Loads and Stores of Floating-Point Values . . . . . . . . . . 107

5 Design Rationale 109

6 CHERI in Programming Languages and Operating Systems 1176.1 Development Plan and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.2 Open-Source Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.3 Current Software Implementation . . . . . . . . . . . . . . . . . . . . . . . . 1186.4 CheriBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.4.1 Extended GNU Assembler (gas) . . . . . . . . . . . . . . . . . . . . . 1186.5 Extended LLVM/Clang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

6.5.1 Extended CHERI Unit-Test Suite . . . . . . . . . . . . . . . . . . . . 1196.6 Future Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7 Future Directions 1217.1 An Open-Source Research Processor . . . . . . . . . . . . . . . . . . . . . . . 1227.2 Formal Methods for Bluespec . . . . . . . . . . . . . . . . . . . . . . . . . . 1227.3 ABI and Compiler Development . . . . . . . . . . . . . . . . . . . . . . . . . 1227.4 Hardware Capability Support for FreeBSD . . . . . . . . . . . . . . . . . . . . 1237.5 Evaluating Performance and Programmability . . . . . . . . . . . . . . . . . . 123

7

Chapter 1

Introduction

The Capability Hardware Enhanced RISC Instructions (CHERI) architecture extends the com-modity 64-bit MIPS Instruction-Set Architecture (ISA) with new security primitives to allowsoftware to efficiently implement fine-grained memory protection and an object-capabilitysecurity model. CHERI’s extensions are intended to support incrementally adoptable, high-performance, formally supported, and programmer-friendly underpinnings for robust and scal-able software compartmentalization motivated by the principle of least privilege. CHERI is ahybrid capability-system architecture in that gradual deployment of CHERI features in existingsoftware is possible, offering a more gentle software adoption path. CHERI has four centraldesign goals aimed at dramatically improving the security of contemporary Trusted Comput-ing Bases (TCBs) through processor support for fine-grained memory protection and scalablesoftware compartmentalization, which at times may conflict:

1. Granular memory protection improves software resilience to escalation paths that allowsoftware bugs to be coerced into more powerful software vulnerabilities; e.g., throughremote code injection via buffer overflows and other memory-based techniques. Unlikewidely deployed approaches, CHERI’s memory protection is intended to be driven bythe compiler in protecting programmer-described data structures and references, ratherthan via coarse page-granularity protections. Fine-grained protection also provides thefoundation for expressing compartmentalization within application instances.

2. Compartmentalization involves the decomposition of software into isolated componentsto mitigate the effects of security vulnerabilities by applying sound principles of security,such as abstraction, encapsulation, and especially least privilege. Previously, it seemsthat the adoption of compartmentalization has been limited by a conflation of hard-ware primitives for virtual addressing and separation, leading to inherent performanceand programmability problems when implementing fine-grained separation. Specifi-cally, we seek to decouple the virtualization from separation to avoid scalability prob-lems imposed by translation look-aside buffer (TLB)-based Memory Management Units(MMUs), which impose a very high performance penalty as the number of protectiondomains increases, as well as complicating the writing of compartmentalized software.

3. Simultaneously, we require a realistic technology transition path that is applicable tocurrent software and hardware designs. CHERI must be able to run most current soft-ware without significant modification, and allow incremental deployment of security im-provements starting with the most critical software components: the TCB foundations

8

on which the remainder of the system rests, and software with the greatest exposure torisk. CHERI features should significantly improve security so that vendors of mobile andembedded devices would seek its feature set from CPU companies (such as MIPS andARM); these CHERI features must at the same time conform to vendor expectations forperformance, power use, and compatibility to compete with less secure alternatives.

4. Finally, we wish to draw on formal methodologies wherever feasible to improve our con-fidence in the design and implementation of CHERI. This use is necessarily subject toreal-world constraints of timeline, budget, design process, and prototyping, but will helpensure that we avoid creating a system that cannot meet our functional and security re-quirements. Formal methods can also help to avoid many of the characteristic designflaws that are common in both hardware and software. This desire requires us not only toperform research into CPU and software design, but also to develop new formal method-ologies and adaptations and extensions of existing ones.

We are concerned with trustworthy systems and networks, where trustworthiness is a mul-tidimensional measure of how well a system or other entity satisfies its various requirements –such as those for security, system integrity, and reliability, as well as survivability, robustness,and resilience, notably in the presence of a wide range of adversities such as hardware failures,software flaws, malware, accidental and intentional misuse, and so on. Our approach to trust-worthiness encompasses hardware and software architecture, dynamic and static evaluation,formal and nonformal analyses, good software engineering practices, and much more.

Our selection of RISC as a foundation for the CHERI capability extensions is motivated bytwo factors. First, simple instruction set architectures are easier to reason about, extend, andimplement. Second, RISC architectures (such as ARM and MIPS) are widely used in networkembedded and mobile device systems such as firewalls, routers, smart phones, and tablets –markets with the perceived flexibility to adopt new CPU facilities, and also an immediate andpressing need for improved security. CHERI’s new security primitives would also be useful inworkstation and server environments, which face similar security challenges.

In its current incarnation, we have prototyped CHERI as an additional coprocessor to the64-bit MIPS ISA, but our approach is intended to easily support other similar ISAs, such as64-bit ARM. The design principles would also apply to other non-RISC ISAs, such as 32-bitand 64-bit Intel and AMD, but require significantly more adaptation work, as well as carefulconsideration of the implications of the diverse set of CPU features found in more CISC-like ar-chitectures. We also consider the possibility that the syntax and semantics of the CHERI modelmight be implemented over conventional CPUs with the help of the compiler, static check-ing, and dynamic enforcement approaches found in software fault isolation techniques [70] orGoogle Native Client (NaCl) [85]. All of these future considerations are considerably enhancedby our use of Bluespec, which provides significant opportunities for rapid redesigns through itsuse of modular abstraction, encapsulation, and hierarchicalization.

1.1 Motivation

The CHERI CPU architecture provides a hardware foundation for principled, secure systems.Its design builds on and extends decades of research into hardware and operating-system secu-

9

rity.1 However, some of the historic approaches that CHERI incorporates (especially capabilityarchitectures) have not been adopted in commodity hardware designs. In light of these pasttransition failures, a reasonable question is “Why now?” What has changed that would allowCHERI to succeed where so many previous efforts have failed? Several factors have motivatedour decision to begin and carry out this project:

• Dramatic changes in threat models, resulting from ubiquitous connectivity and perva-sive uses of computer technology in many diverse and widely used applications such aswireless mobile devices, automobiles, and critical infrastructure.

• New opportunities for research into (and possible revisions of) hardware-software in-terfaces, brought about by programmable hardware (especially FPGA soft cores) andcomplete open-source software stacks.

• An increasing trend towards exposing inherent hardware parallelism through virtual ma-chines and explicit software multi-programming, and an increasing awareness of infor-mation flow for reasons of power and performance that may align well with the require-ments of security.

• Emerging advances in programming languages, such as the ability to map language struc-tures into protection parameters to more easily express and implement various policies.

• Reaching the tail end of a “compatibility at all costs” trend in CPU design, due to prox-imity to physical limits on clock rates and trends towards heterogeneous and distributedcomputing. While Wintel remains entrenched on the desktop, mobile systems – such asphones and tablet PCs, as well as appliances and embedded devices – are much morediverse, running on a wide variety of instruction set architectures (especially ARM andMIPS).

• Likewise, new diversity in operating systems has arisen, in which commercial productssuch as Apple’s iOS and Google’s Android extend open-source systems such as FreeBSDand Linux. These new platforms abandon many traditional constraints, requiring thatrewritten applications conform to new security models, programming languages, hard-ware architectures, and user-input modalities.

• Development of hybrid capability-system models that integrate capability-system designtenets into current operating-system and language designs. With CHERI, we are trans-posing this design philosophy into the instruction-set architecture. Hybrid design is a keydifferentiator from prior capability-system hardware designs that have typically requiredground-up software-architecture redesign and reimplementation.

• Significant changes in the combination of hardware, software, and formal methods toenhance assurance (such as those noted above) now make possible the development oftrustworthy system architectures that previously were simply too far ahead of their times.

1Levy’s Capability-Based Computer Systems provides a detailed history of segment- and capability-baseddesigns through the early 1990s [38]. However, it leaves off just as the transition to microkernel-based capabilitysystems such as Mach [1] and L4 [39], as well as capability-influenced virtual machines such as the Java VirtualMachine [21], begins. Section 1.6 discuss historical influences on this work in greater detail.

10

In the following sections, we consider the context and motivation for CHERI, a high-levelview of the CHERI design, the role of formal methods in the project, and our work-in-progressresearch prototype.

1.1.1 Trusted Computing Bases (TCBs)

Contemporary client-server and cloud computing are premised on highly distributed applica-tions, with end-user components executing in rich execution substrates such as POSIX appli-cations on UNIX, or AJAX in web browsers. However, even thin clients are not thin in mostpractical senses: as with client-server computer systems, they are built from commodity op-erating system kernels, hundreds of user-space libraries, window servers, language runtimeenvironments, and web browsers, which themselves include scripting language interpreters,virtual machines, and rendering engines. Both server and embedded systems likewise dependon complex (and quite similar) software stacks. All require confluence of competing interests,representing multiple sites, tasks, and end users in unified computing environments.

Whereas higher-layer applications are able to run on top of type-safe or constrained exe-cution environments, such as JavaScript interpreters, lower layers of the system must providethe link to actual execution on hardware. As a result, almost all such systems are written in theC programming language; collectively, this Trusted Computing Base (TCB) consists of manytens of millions of lines of trusted (but not trustworthy) C and C++ code. Coarse hardware, OS,and language security models mean that much of this code is security-sensitive: a single flaw,such as an errant NULL pointer dereference in the kernel, can expose all rights held by usersof a system to an attacker or to malware.

The consequences of compromise are serious, and include loss of data, release of personalor confidential information, damage to system and data integrity, and even total subversion of auser’s online presence and experience by the attacker (or even accidentally without any attackerpresence!). These problems are compounded by the observation that the end-user systems arealso an epicenter for multi-party security composition, where a single web browser or officesuite (which manages state, user interface, and code execution for countless different securitydomains) must simultaneously provide strong isolation and appropriate sharing. The resultspresent not only significant risks of compromise that lead to financial loss or disruption ofcritical infrastructure, but also frequent occurrences of such events.

Software vulnerabilities appear inevitable: even as the execution substrates improve in theirability to resist attacks such as buffer overflows and integer vulnerabilities, logical errors willnecessarily persist. Past research has shown that compartmentalizing applications into compo-nents executed in isolated sandboxes can mitigate exploited vulnerabilities (sometimes referredto as privilege separation). Only the rights held by a compromised component are accessible toa successful attacker. This technique is effectively applied in Google’s Chromium web browser,placing HTML rendering and JavaScript interpretation into sandboxes isolated from the globalfile system. This technique exploits the principle of least privilege: if each software elementexecutes with only the rights required to perform its task, then attackers lose access to mostall-or-nothing toeholds; vulnerabilities may be significantly or entirely mitigated, and attackersmust identify many more vulnerabilities to accomplish their goals.

11

1.1.2 The Compartmentalization Problem

The compartmentalization problem arises from attempts to decompose security-critical appli-cations into components running in different security domains: the practical application ofthe principle of least privilege to software. Historically, compartmentalization of TCB com-ponents such as operating system kernels and central system services has caused significantdifficulty for software developers – which limits its applicability for large-scale, real-worldapplications, and leads to the abandonment of promising research such as 1990s microker-nel projects. A recent resurgence of compartmentalization, applied in userspace to applica-tions such as OpenSSH [56] and Chromium [58], and most recently in our own Capsicumproject [76], has been motivated by a critical security need; however it has seen success only atvery coarse separation granularity due to the challenges involved.

On current conventional hardware, native applications must be converted to employ mes-sage passing between address spaces (or processes) rather than using a unified address spacefor communication, sacrificing programmability and performance by transforming a local pro-gramming problem into a distributed systems problem. As a result, large-scale compartmental-ized applications are difficult to design, write, debug, maintain, and extend; this raises seriousquestions about correctness, performance, and most critically, security.

These problems occur because current hardware provides strong separation only at coarsegranularity via rings and virtual address spaces, making the isolation of complete applications(or even multiple operating systems) a simple task, but complicates efficient and easily ex-pressed separation between tightly coupled software components. Three closely related prob-lems arise:

Performance is sacrificed. Creating and switching between security domains is expensivedue to reliance on software and hardware address-space infrastructure, such as a quickly over-flowed Translation Look-aside Buffer (TLB) that can lead to massive performance degrada-tion. Also, above an extremely low threshold, performance overhead from context switchingbetween security domains tends to go from extremely expensive to intolerable: each TLB entryis an access-control list, with each object (page) requiring multiple TLB entries, one for eachauthorized security domain.

High-end server CPUs typically have TLB entries in the low hundreds, and even recent net-work embedded devices reach the low thousands; the TLB footprint of fine-grained, compart-mentalized software increases with the product of in-flight security domains and objects due toTLB aliasing, which may easily require tens or hundreds of thousands of spheres of protection.The transition to CPU multi-threading has not only failed to relieve this burden, but activelymade it worse: TLBs are implemented using ternary content-addressable memory (TCAMs) orother expensive hardware lookup functions, and are often shared between hardware threads ina single core due to their expense.

In comparison, physically indexed general-purpose CPU caches are several orders of mag-nitude larger than TLBs, scaling instead with the working set of code paths explored or thememory footprint of data actively being used. If the same data is accessed by multiple securitydomains, it shares data or code cache (but not TLB entries) with current CPU designs.

Programmability is sacrificed. Within a single address space, programmers can easily andefficiently share memory between application elements using pointers from a common names-

12

pace. The move to multiple processes frequently requires the adoption of a distributed program-ming model based on explicit message passing, making development, debugging, and testingmore difficult. RPC systems and higher-level languages are able to mask some (although usu-ally not all) of these limitations, but are poorly suited for use in TCBs – RPC systems and pro-gramming language runtimes are non-trivial, security-critical, and implemented using weakerlower-level facilities.2

Security is sacrificed. Current hardware is intended to provide robust shared memory com-munication only between mutually trusting parties, or at significant additional expense; gran-ularity of delegation is limited and its primitives expensive, leading to programmer error andextremely limited use of granular separation. Poor programmability contributes directly to poorsecurity properties.

1.2 The CHERI DesignCHERI embodies two fundamental and closely linked technical goals to address vulnerabilitymitigation: first, fine-grained capability-oriented memory protection within address spaces,and second, primitives to support both scalable and programmer-friendly compartmentalizationwithin address spaces based on the object-capability model. The CHERI model is designed tosupport low-level TCBs, typically implemented in C or a C-like language, in workstations,servers, mobile devices, and embedded devices. Simultaneously, it will provide reasonableassurance of correctness and a realistic technology transition path from existing hardware andsoftware platforms.

To this end, we have prototyped CHERI as an Instruction-Set Architecture (ISA) extensionto the widely used 64-bit MIPS ISA; we are also considering the implications for the RISC-Vand ARM ISAs. CHERI adds the following features to a RISC CPU design via a new capabilitycoprocessor that supports granular memory protection within address spaces:

• The capability register file describes the rights (protection domain) of the executingthread to memory that it can access, and to object references that can be invoked to tran-sition between protection domains. Capability registers supplement the general-purposeregister file, allowing capabilities to displace general-purpose registers in describing dataand object references. Certain registers are reserved for use in exception handling; allothers are available to be managed by the compiler using the same techniques used withconventional registers.

• A set of capability instructions allow executing code to create, constrain (e.g., by in-creasing the base, decreasing the length, or reducing permissions), manage, and inspectcapability register values. Both data and further capabilities can be loaded and stored viacapability registers (i.e., dereferencing); object capabilities can be invoked, via special

2Through extreme discipline, a programming model can be constructed that maintains synchronized mappingsof multiple address spaces, while granting different rights on memory between different processes. This leadsto even greater TLB pressure and expensive context switch operations, as the layouts of address spaces must bemanaged using cross-address-space communication. Bittau has implemented this model via sthreads, an OS prim-itive that tightly couples UNIX processes via shared memory associated with data types – a promising separationapproach constrained by the realities of current CPU design [8].

13

instructions, allowing a transition between protection domains. Invalid capability ma-nipulations (e.g., to increase rights or length) and invalid capability dereferences (e.g.,to access outside of a bounds-checked region) result in an exception that can be handledby the supervisor or language runtime. Most capability instructions are part of the user-mode ISA, rather than privileged ISA, and will be generated by the compiler to describeapplication data structures and protection properties.

• Tagged memory associates a 1-bit tag with each capability-aligned and capability-sizedword in physical memory, which allows capabilities to be safely loaded and stored inmemory without loss of integrity. This functionality expands a thread’s effective pro-tection domain to include the transitive closure of capability values that can be loadedvia capabilities via those present in its register file. For example, a capability registerrepresenting a C pointer to a data structure can be used to load further capabilities fromthat structure, referring to further data structures, which could not be accessed withoutsuitable capabilities. Writes to capability values in memory that do not originate froma valid capability in the capability-register file will clear the tag bit associated with thatmemory, preventing accidental (or malicious) dereferencing of invalid capabilities.

In keeping with the RISC philosophy, CHERI instructions are intended for use primar-ily by the compiler rather than directly by the programmer, and consist of relatively simpleinstructions that avoid, for example, combining memory access and register value manipu-lation in a single instruction. In our current software prototypes, there are direct mappingsfrom programmer-visible, C-language pointers to capabilities in much the same way that con-ventional code generation translates pointers into general-purpose register values; this allowsCHERI to continuously enforce bounds checking, pointer integrity, and so on. There is likewisea strong synergy between the capability-system model, which espouses a separation of policyand mechanism, and RISC: CHERI’s features make possible the implemention of a wide vari-ety of OS, compiler, and application-originated policies on a common protection substrate thatoptimizes fast paths through hardware support.

The capability coprocessor is a coprocessor in two senses. First, the capability coprocessoroccupies a portion of the existing ISA encoding dedicated to extensions (typically referred to ascoprocessor instructions). Second, the capability coprocessor supplements the general-purposeregister file with its own ISA-managed registers, as well as performing (and transforming)memory access, and delivering exceptions to the main pipeline, requiring hardware resourcesthat interact with the primary processor pipeline. This behavior is comparable in many ways tosystem, floating-point, vector, or cryptographic coprocessors that will similarly supplement thebase ISA and processor features.

Wherever possible, CHERI systems make use of existing hardware designs: processorpipelines and register files, cache memory, system buses, commodity DRAM, and commodityperipheral devices such as NICs and display cards. We are currently focusing on enforcementof CHERI security properties on applications running on a general-purpose processor; in futurework, we hope to consider the effects of implementing CHERI in peripheral processors, suchas those found in Network Interface Cards (NICs) or Graphical Processing Units (GPUs).

In order to prototype this approach, we have localized our ideas about CHERI capabilityaccess to a specific instruction set: the 64-bit MIPS ISA. This has necessarily led to a set ofcongruent implementation decisions about register-file size, selection of specific instructions,exception handling, memory alignment requirements, and so on, that reflect that starting-point

14

ISA. These decisions might be made differently with another starting-point ISA as they are sim-ply surface features of an underlying approach; we anticipate that adaptations to ISAs such asARM and RISC-V would adopt instruction-encoding conventions, and so on, more in keepingwith their specific flavor and approach.

Other design decisions reflect the goal of creating a platform for prototyping and exploringthe design space itself; among other choices, this includes the selection of 256-bit capabili-ties, which have given us greater flexibility to experiment with various bounds-checking andcapability behaviors. Reducing capabilities to 128-bit is not unreasonable, and measurementssuggest that cache footprint increases from capabilities can be significantly mitigated throughsuch a change. However, this would also introduce tradeoffs in the granularity of memory (e.g.,losing access to the full 64-bit space) and flexibility of the object-capability design (e.g., lossof software-defined permission bits) that would need to be reasoned about carefully.

We believe, however, that the higher-level memory protection and security models we havedescribed would relatively easily apply to variations in ISA-level implementation. This shouldallow reasonable source-level software portability (leaving aside OS assembly code and com-piler code generation) across the CHERI model implemented in different architectures, in muchthe same way that conventional OS and application C code is moderately portable across un-derlying ISAs.

1.2.1 A Hybrid Capability-System Architecture

Unlike past research into capability systems, CHERI allows traditional address-space separa-tion, implemented using a memory management unit (MMU), to coexist with granular decom-position of software within each address space. As a result, fine-grained memory protection andcompartmentalization can be applied selectively throughout existing software stacks to providean incremental software migration path. We envision early deployment of CHERI extensions inselected components of the TCB’s software stack: separation kernels, operating system kernels,programming language runtimes, sensitive libraries such as those involved in data compressionor encryption, and network applications such as web browsers and web servers.

CHERI addresses current limitations on compartmentalization by extending virtual memory-based separation with hardware-enforced, fine-grained protection within address spaces. Gran-ular memory protection mitigates a broad range of previously exploitable bugs by coercingcommon memory-related failures into exceptions that can be handled by the application or op-erating system, rather than yielding control to the attacker. The CHERI approach also restoresa single address-space programming model for compartmentalized (sandboxed) software, fa-cilitating efficient, programmable, and robust separation through the capability model.

We have selected this specific composition of traditional virtual memory with an in-address-space security model to facilitate technology transition: in CHERI, existing C-based softwarecan continue to run within processes, and even integrate with capability-enhanced softwarewithin a single process, to provide improved robustness for selected software components –and perhaps over time, all software components. For example, a sensitive library (perhaps usedfor image processing) might employ capability features while executing as part of a CHERI-unaware web browser. Likewise, a CHERI-enabled application can sandbox and instantiatemultiple copies of unmodified libraries, to efficiently and easily gate access to the rest of appli-cation memory of the host execution environment.

15

1.3 Threat Model

CHERI protections constrain code “in execution” and allow fine-grained management of priv-ilege within a framework for controlled separation and communication. Code in executioncan represent the focus of many potentially malicious parties: subversion of legitimate codein violation of security policies, injection of malicious code via back doors, trojan horses, andmalware, and also denial-of-service attacks. CHERI’s fine-grained memory protection miti-gates many common attack techniques by reducing opportunities for the conflation of code anddata, as well as catching many common exploitable programmer bugs; compartmentalizationconstrains successful attacks via the principle of least privilege.

Physical attacks on CHERI-based systems are explicitly excluded from our threat model, al-though CHERI CPUs might easily be used in the context of tamper-evident or tamper-resistantsystems. Similarly, no special steps have been taken in our design to counter undesired leakageof electromagnetic emanations and certain other side channels such as acoustic inferences: wetake for granted the presence of an electronic foundation on which CHERI can run. CHERIwill provide a supportive framework for a broad variety of security-sensitive activities; whilenot itself a distributed system, CHERI could form a sound foundation for various forms ofdistributed trustworthiness.

Somewhat to our chagrin, we report that the CHERI design currently includes no featuresfor resisting covert or side-channel attacks: these have proven increasingly relevant in CPUdesign, but the tools CHERI provides do not improve resilience against these attacks. In somesense, they increase exposure: the greater the offers of protection within a system, the greaterthe potential impact of unauthorized communication channels. As such, we hope side-channelattacks are a topic that we will be able to explore in future work. Overall, we believe that ourthreat model is realistic and will lead to systems that can be substantially more trustworthy thantoday’s commodity systems.

1.4 Formal Methodology

Throughout this project, we apply formal methodology to help avoid system vulnerabilities.An important early observation is that existing formal methodology applied to software se-curity has significant problems with multi-address-space security models; formal approacheshave relied on the usefulness of addresses (pointers) as unique names for objects. Whereas thisweakness in formal methods is a significant problem for traditional CPU designs, which offersecurity primarily through rings and address-space translation, CHERI’s capability model isscoped within address spaces. This offers the possibility of applying existing software proofmethodology in the context of hardware isolation (and other related properties) in a manner thatwas previously infeasible. We are more concretely (and judiciously) applying formal method-ology in two areas:

1. We have developed a formal semantics for the CHERI ISA described in SRI’s Proto-type Verification System (PVS) – an automated theorem-proving and model-checkingtoolchain – which can be used to verify the expressibility of the ISA, but also to proveproperties of critical code. For example, we are interested in proving the correctness ofsoftware-based address-space management and domain transitions. We are likewise able

16

to automatically generate ISA-level test suites from formal descriptions of instructions,which are applied directly to our hardware implementation.

2. We have developed extensions to the Bluespec compiler to export an HDL descriptionto SRI’s PVS and SAL model checker. We have also developed new tools for efficientSMT (Satisfiability Modulo Theories) modeling of designs (using SRI’s Yices), and theautomated extraction of key properties from larger Bluespec designs. These tools willallow us to verify low-level properties of the hardware design and use the power of modelchecking and satisfiability solvers to analyze related properties. Ideally they will alsohelp link ISA-level specifications with the CPU implementation.

A detailed description of formal methods efforts relating to CHERI may be found in the to-be-published CHERI Formal Methods Report.

1.5 CHERI and CHERI2 Reference PrototypesAs a central part of this research, we are developing reference prototypes of the CHERI ISA viaseveral CHERI processor designs. These protoypes allow us to explore, validate, evaluate, anddemonstrate the CHERI approach through realistic hardware properties and real-world softwarestacks. A detailed description of the current prototypes, both from architectural and practicaluse perspectives, may be found in the companion BERI Hardware Reference, BERI SoftwareReference, and CHERI User’s Guide documents.

Our first prototype, known simply as CHERI1, is based on Cambridge’s MAMBA researchprocessor, and is a single-threaded, single-core implementation intended to allow us to exploreISA tradeoffs. This prototype is implemented in the Bluespec HDL, a high-level functionalprogramming language for hardware design. CHERI1 is a pipelined baseline processor imple-menting the 64-bit MIPS ISA, and incorporates an initial prototype of the CHERI capabilitycoprocessor that includes capability registers and a basic capability instruction set.

We have ported the commodity open-source FreeBSD operating system, with support fora wide variety of peripherals on the Terasic tPad and DE4 FPGA development boards; we usethese boards in both mobile tablet-style and network configurations. FreeBSD is able to man-age the capability coprocessor and maintain additional thread state for capability-aware userapplications, although capability features are not yet used within the kernel for its own internalprotection. FreeBSD also implements exception-handler support for object-capability invo-cation, signal delivery when protection faults occur (allowing language runtimes to catch andhandle protection violations), and error recovery for in-process sandboxes. We have adapted theClang and LLVM compiler suite to allow language-level annotations in C to direct capabilityuse. In addition, we have developed a number of capability-enhanced applications demonstrat-ing fine-grained memory protection and in-process compartmentalization to explore security,performance, and programmability tradeoffs. We also have a work-in-progress multi-core ver-sion of the CHERI prototype.

Using Bluespec, we are able to run the CPU in simulation, and synthesize the CHERIdesign to execute in field-programmable gate arrays (FPGAs). In our development work, we aretargeting an Altera FPGAs on Terasic development boards. However, in our companion MRCproject we have also targeted CHERI at the second-generation NetFPGA 10G research andteaching board, which we hope to use in ongoing research into datacenter network fabrics. That

17

work includes the development of Blueswitch, a Bluespec implementation of an OpenFlowswitch that can operate as a tightly coupled CHERI coprocessor. In the future, should it becomedesirable, we will be able to construct an ASIC design from the same Bluespec source code.We have released the CHERI soft core as open-source hardware, making it available for morewidespread use in research. This should allow others, especially in the research community, toreproduce and extend our results.

We have also developed a second prototype, known as CHERI2, which deploys addi-tional CPU features, such as support for multi-core operation and simultaneous multi-threading(SMT) support. It also employs a more stylized form of Bluespec that is intended to consider-ably enhance our formal analysis of the hardware architecure.

1.6 Historical Context

As with many aspects of contemporary computer and operating system design, the origins ofoperating system security may be found at the world’s leading research universities, but es-pecially the Massachusetts Institute of Technology (MIT), the University of Cambridge, andCarnegie Mellon University. MIT’s Project MAC, which began with MIT’s Compatible TimeSharing System (CTSS) [12], and continued over the next decade with MIT’s Multics project,described many central tenets of computer security [13, 24]. Dennis and Van Horn’s 1965 Pro-gramming Semantics for Multiprogrammed Computations [16] laid out principled hardwareand software approaches to concurrency, object naming, and security for multi-programmedcomputer systems – or, as they are known today, multi-tasking and multi-user computer sys-tems. Multics implemented a coherent, unified architecture for processes, virtual memory,and protection, integrating new ideas such as capabilities, unforgeable tokens of authority, andprincipals, the end users with whom authentication takes place and to whom resources areaccounted [63].

In 1975, Saltzer and Schroeder surveyed the rapidly expanding vocabulary of computer se-curity in The Protection of Information in Computer Systems [64]. They enumerated designprinciples such as the principle of least privilege (which demands that computations run withonly the privileges they require) and the core security goals of protecting confidentiality, in-tegrity, and availability. The tension between fault tolerance and security (a recurring debatein systems literature) saw its initial analysis in Lampson’s 1974 Redundancy and Robustnessin Memory Protection [33], which considered ways in which hardware memory protection ad-dressed accidental and intentional types of failure: if it is not reliable, it will not be secure,and if it is not secure, it will not be reliable! Intriguingly, recent work by Nancy Leveson andWilliam Young has unified security and human safety as overarching emergent system proper-ties [37], and allows the threat model to fall out of the top-down analysis, rather than drivingit. This work in some sense unifies a long thread of work that considers trustworthiness asa property encompassing security, integrity, reliablity, survivability, human safety, and so on(e.g., [50, 51], among others).

The Security Research community also blossomed outside of MIT: Wulf’s Hydra operat-ing system at Carnegie Mellon University (CMU) [83, 11], Needham and Wilkes’ CAP Com-puter at Cambridge [81], SRI’s Provably Secure Operating System (PSOS) [19, 51] hardware-software co-design that included strongly typed object capabilities, Rushby’s security kernelssupported by formal methods at Newcastle [62], and Lampson’s work on formal models of se-

18

curity protection at the Berkeley Computer Corporation all explored the structure of operatingsystem access control, and especially the application of capabilities to the protection prob-lem [34, 35]. Another critical offshoot from the Multics project was Ritchie and Thompson’sUNIX operating system at Bell Labs, which simplified concepts from Multics, and became thebasis for countless directly and indirectly derived products such as today’s Solaris, FreeBSD,Mac OS X, and Linux operating systems [60].

The creation of secure software went hand in hand with analysis of security flaws: Ander-son’s 1972 US Air Force Computer Security Technology Planning Study not only defined newsecurity structures, such as the reference monitor, but also analyzed potential attack method-ologies such as Trojan horses and inference attacks [3]. Karger and Schell’s 1974 report on asecurity analysis of the Multics system similarly demonstrated a variety of attacks that bypasshardware and OS protection [29]. In 1978, Bisbey and Hollingworth’s Protection Analysis:Project final report at ISI identified common patterns of security vulnerability in operatingsystem design, such as race conditions and incorrectly validated arguments at security bound-aries [7]. Adversarial analysis of system security remains as critical to the success of securityresearch as principled engineering and formal methods.

Almost fifty years of research have explored these and other concepts in great detail, bring-ing new contributions in hardware, software, language design, and formal methods, as well asnetworking and cryptography technologies that transform the context of operating system secu-rity. However, the themes identified in those early years remain topical and highly influential,structuring current thinking about systems design.

Over the next few sections, we consider three closely related ideas that directly influenceour thinking for CTSRD: capability security, microkernel OS design, and language-based con-straints. These apparently disparate areas of research are linked by a duality, observed by Mor-ris in 1973, between the enforcement of data types and safety goals in programming languageson one hand, and the hardware and software protection techniques explored in operating sys-tems [47] on the other hand. Each of these approaches blends a combination of limits definedby static analysis (perhaps at compile-time), limits on expression on the execution substrate(such as what programming constructs can even be represented), and dynamically enforcedpolicy that generates runtime exceptions (often driven by the need for configurable policy andlabeling not known until the moment of access). Different systems make different uses of thesetechniques, affecting expressibility, performance, and assurance.

1.6.1 Capability Systems

Throughout the 1970s and 1980s, high-assurance systems were expected to employ a capability-oriented design that would map program structure and security policy into hardware enforce-ment; for example, Lampson’s BCC design exploited this linkage to approximate least privi-lege [34, 35].

Systems such as the CAP Computer at Cambridge [81] and Ackerman’s DEC PDP-1 archi-tecture at MIT [2] attempted to realize this vision through embedding notions of capabilities inthe memory management unit of the CPU, an approach described by Dennis and Van Horn [16].Levy provides a detailed exploration of segment- and capability-oriented computer system de-sign through the mid-1980s in Capability-Based Computer Systems [38].

19

VFS

Operating system kernel

Proc 1 Proc 2

/e

hb

a

libfoolibc

rtld

libfoolibc

rtld

libfoolibc

rtld

ring 1

ring 3/e

hb

a

Figure 1.1: The microkernel movement shifted complex OS components, such as file systems,from the kernel to userspace tasks linked by IPC. Microkernels provide a smaller, easier-to-analyze, easier-to-debug, and more robust foundation in the face of dramatic increases in OScomplexity.

1.6.2 MicrokernelsDenning has argued that the failures of capability hardware projects were classic failures oflarge systems projects, an underestimation of the complexity and cost of reworking an entiresystem design, rather than fundamental failures of the capability model [15]. However, thebenefit of hindsight suggests that the earlier demise of hardware capability systems was a resultof three related developments in systems research: microkernel OS design, a related interestfrom the security research community in security kernel design, and Patterson and Sequin’sReduced Instruction-Set Computers (RISC) [55].

However, with a transition from complex instruction set computers (CISC) to reduced in-struction set computers (RISC), and a shift away from microcode toward operating systemimplementation of complex CPU functionality, the attention of security researchers turned tomicrokernels.

Carnegie Mellon’s Hydra [11, 84] embodied this approach, in which microkernel messagepassing between separate tasks stood in for hardware-assisted security domain crossings atcapability invocation. Hydra developed a number of ideas, including the relationship betweencapabilities and object references, refined the object-capability paradigm, and further pursuedthe separation of policy and mechanism.3 Jones and Wulf argue through the Hydra design thatthe capability model allows the representation of a broad range of system policies as a resultof integration with the OS object model, which in turn facilitates interposition as a means ofimposing policies on object access [27].

Successors to Hydra at CMU include Accent and Mach [57, 1], both microkernel systemsintended to explore the decomposition of a large and decidedly un-robust operating systemkernel. Figure 1.1 illustrates the principle of microkernel design: traditional OS services, suchas the file system, are migrated out of ring 0 and into user processes, improving debuggabilityand independence of failure modes. They are also based on mapping of capabilities as object

3Miller has expanded on the object-capability philosophy in considerable depth in his 2006 PhD dissertation,Robust composition: towards a unified approach to access control and concurrency control [45]

20

references into IPC pipes (ports), in which messages on ports represent methods on objects.This shift in operating system design went hand in hand with a related analysis in the securitycommunity: Lampson’s model for capability security was, in fact, based on pure messagepassing between isolated processes [35]. This further aligned with proposals by Andrews [4]and Rushby [62] for a security kernel, whose responsibility lies solely in maintaining isolation,rather than the provision of higher-level services such as file systems. Unfortunately, the shiftto message passing also invalidated Fabry’s semantic argument for capability systems, namely,that by offering a single namespace shared by all protection domains, the distributed systemprogramming problem could be avoided [18].

A panel at the 1974 National Computer Conference and Exposition (AFIPS) chaired byLipner brought the design goals and choices for microkernels and security kernels clearly intofocus: microkernel developers sought to provide flexible platforms for OS research with an eyetowards protection, while security kernel developers aimed for a high assurance platform forseparation, supported by hardware, software, and formal methods [40].

The notion that the microkernel, rather than the hardware, is responsible for implement-ing the protection semantics of capabilities also aligned well with the simultaneous research(and successful technology transfer) of RISC designs, which eschewed microcode by shift-ing complexity to the compiler and operating system. Without microcode, the complex C-list peregrinations of CAP’s capability unit, and protection domain transitions found in othercapability-based systems, become less feasible in hardware. Simple virtual memory designsbased on fixed-size pages and few semantic constraints have since been standardized through-out the industry.

Security kernel designs, which combine a minimal kernel focused entirely on correctly im-plementing protection, and rigorous application of formal methods, formed the foundation forseveral secure OS projects during the 1970s. Schiller’s security kernel for the PDP-11/45 [65]and Neumann’s Provably Secure Operating System [20] design study were ground-up operatingsystem designs based soundly in formal methodology.4 In contrast, Schroeder’s MLS kerneldesign for Multics [66], the DoD Kernelized Secure Operating System (KSOS) [42], and BruceWalker’s UCLA UNIX Security Kernel [71] attempted to slide MLS kernels underneath ex-isting Multics and UNIX system designs. Steve Walker’s 1980 survey of the state of the art intrusted operating systems provides a summary of the goals and designs of these high-assurancesecurity kernel designs [72].

The advent of CMU’s Mach microkernel triggered a wave of new research into security ker-nels. TIS’s Trusted Mach (TMach) project extended Mach to include mandatory access control,relying on enforcement in the microkernel and a small number of security-related servers to im-plement the TCB to accomplish sufficient assurance for a TCSEC B3 evaluation [9]. SecureComputing Corporation (SCC) and the National Security Agency (NSA) adapted PSOS’s typeenforcement from LoCK (LOgical Coprocessor Kernel) for use in a new Distributed TrustedMach (DTMach) prototype, which built on the TMach approach while adding new flexibil-ity [67]. DTMach, adopting ideas from Hydra, separates mechanism (in the microkernel) frompolicy (implemented in a userspace security server) via a new reference monitor framework,FLASK [69]. A significant focus of the FLASK work was performance: an access vector cacheis responsible for caching access control decisions throughout the OS to avoid costly up-callsand message passing (with associated context switches) to the security server. NSA and SCC

4PSOS’s ground-up design included ground-up hardware, whereas Schiller’s design revised only the softwarestack.

21

eventually migrated FLASK to the FLUX microkernel developed by the University of Utah inthe search for improved performance. Invigorated by the rise of microkernels and their con-gruence with security kernels, this flurry of operating system security research also faced thelimitations (and eventual rejection) of the microkernel approach by the computer industry –which perceived the performance overheads as too great.

Microkernels and mandatory access control have seen another experimental composition inthe form of Decentralized Information Flow Control (DIFC). This model, proposed by Myers,allows applications to assign information flow labels to OS-provided objects, such as commu-nication channels, which are propagated and enforced by a blend of static analysis and runtimeOS enforcement, implementing policies such as taint tracking [48] – effectively, a compositionof mandatory access control and capabilities in service to application security. This approachis embodied by Efstathopoulos et al.’s Asbestos [17] and Zeldovich et al.’s Histar [87] researchoperating systems.

Despite the decline of both hardware-oriented and microkernel capability system design,capability models continue to interest both research and industry. Inspired by the propri-etary KEYKOS system [25], Shapiro’s EROS [68] (now CapROS) continues the investiga-tion of higher-assurance software capability designs, seL4 [31], a formally verified, capability-oriented microkernel, has also continued along this avenue. General-purpose systems also haveadopted elements of the microkernel capability design philosophy, such as Apple’s Mac OSX [5] (which uses Mach interprocess communication (IPC) objects as capabilities) and Cam-bridge’s Capsicum [76] research project (which attempts to blend capability-oriented designwith UNIX).

More influentially, Morris’s suggestion of capabilities at the programming language levelhas seen widespread deployment. Gosling and Gong’s Java security model blends language-level type safety with a capability-based virtual machine [23, 22]. Java maps language-levelconstructs (such as object member and method protections) into execution constraints enforcedby a combination of a pre-execution bytecode verification and expression constraints in thebytecode itself. Java has seen extensive deployment in containing potentially (and actually) ma-licious code in the web browser environment. Miller’s development of a capability-oriented Elanguage [45], Wagner’s Joe-E capability-safe subset of Java [44], and Miller’s Caja capability-safe subset of JavaScript continue a language-level exploration of capability security [46].

1.6.3 Language and Runtime Approaches

Direct reliance on hardware for enforcement (which is central to both historic and current sys-tems) is not the only approach to isolation enforcement. The notion that limits on expressibilityin a programming language can be used to enforce security properties is frequently deployedin contemporary systems to supplement coarse and high-overhead operating-system processmodels. Two techniques are widely used: virtual-machine instruction sets (or perhaps physi-cal machine instruction subsets) with limited expressibility, and more expressive languages orinstruction sets combined with type systems and formal verification techniques.

The Berkeley Packet Filter (BPF) is one of the most frequently cited examples of the vir-tual machine approach: user processes upload pattern matching programs to the kernel to avoiddata copying and context switching when sniffing network packet data [41]. These programsare expressed in a limited packet-filtering virtual-machine instruction set capable of expressingcommon constructs, such as accumulators, conditional forward jumps, and comparisons, but

22

are incapable of expressing arbitrary pointer arithmetic that could allow escape from confine-ment, or control structures such as loops that might lead to unbounded execution time. Similarapproaches have been used via the type-safe Modula 3 programming language in SPIN [6],and the DTrace instrumentation tool that, like BPF, uses a narrow virtual instruction set toimplement the D language [10].

Google’s Native Client (NaCl) model edges towards a verification-oriented approach, inwhich programs must be implemented using a ‘safe’ (and easily verified) subset of the x86 orARM instruction sets, which would allow confinement properties to be validated [86]. NaClis closely related to Software Fault Isolation (SFI) [70], in which safety properties of machinecode are enforced through instrumentation to ensure no unsafe access, and Proof-CarryingCode (PCC) in which the safe properties of code are demonstrated through attached and easilyverifiable proofs [49]. As mentioned in the previous section, the Java Virtual Machine (JVM)model is similar; it combines runtime execution constraints of a restricted, capability-orientedbytecode with a static verifier run over Java classes before they can be loaded into the execu-tion environment; this ensures that only safe accesses have been expressed. C subsets, suchas Cyclone [26], and type-safe languages such as Ruby [61], offer similar safety guarantees,which can be leveraged to provide security confinement of potentially malicious code withouthardware support.

These techniques offer a variety of trade-offs relative to CPU enforcement of the processmodel. For example, some (BPF, D) limit expressibility that may prevent potentially usefulconstructs from being used, such as loops bounded by invariants rather than instruction limits;in doing so, this can typically impose potentially significant performance overhead. Systemssuch as FreeBSD often support just-in-time compilers (JITs) that convert less efficient virtual-machine bytecode into native code subject to similar constraints, addressing performance butnot expressibility concerns [43].

Systems like PCC that rely on proof techniques have had limited impact in industry, andoften align poorly with widely deployed programming languages (such as C) that make for-mal reasoning difficult. Type-safe languages have gained significant ground over the lastdecade, with widespread use of JavaScript and increasing use of functional languages suchas OCaML [59]; they offer many of the performance benefits with improved expressibility,yet have had little impact on operating system implementations. However, an interesting twiston this view is described by Wong in Gazelle, in which the observation is made that a webbrowser is effectively an operating system by virtue of hosting significant applications and en-forcing confinement between different applications [73]. Web browsers frequently incorporatemany of these techniques including Java Virtual Machines and a JavaScript interpreter.

1.6.4 Influences of Our Own Past Projects

Our CHERI capability hardware design responds to all these design trends – and their prob-lems. Reliance on traditional paged virtual memory for strong address-space separation, as usedin Mach, EROS, and UNIX, comes at significant cost: attempts to compartmentalize systemsoftware and applications sacrifice the programmability benefits of a language-based capabil-ity design (a point made convincingly by Fabry [18]), and introduce significant performanceoverhead to cross-domain security boundaries. However, running these existing software de-signs is critical to improve the odds of technology transfer, and to allow us to incrementallyapply ideas in CHERI to large-scale contemporary applications such as office suites. CHERI’s

23

hybrid approach allows a gradual transition from virtual address separation to capability-basedseparation within a single address space, thus restoring programmability and performance soas to facilitate fine-grained compartmentalization throughout the system and its applications.

We consider some of our own past system designs in greater detail, especially as they relateto CTSRD:

Multics The Multics system incorporated many new concepts in hardware, software, andprogramming [54, 14]. The Multics hardware provided independent virtual memory segments,paging, interprocess and intra-process separation, and cleanly separated address spaces. TheMultics software provided symbolically named files that were dynamically linked for efficientexecution, rings of protection providing layers of security and system integrity, hierarchical di-rectories, and access-control lists. Input-output was also symbolically named and dynamicallylinked, with separation of policy and mechanism, and separation of device independence anddevice dependence. A subsequent redevelopment of the two inner-most rings enabled Multicsto support multilevel security in the commercial product. Multics was implemented in a starksubset of PL/I that considerably diminished the likelihood of many common programming er-rors. In addition, the stack discipline inherently avoided buffer overflows.

PSOS SRI’s Provably Secure Operating System hardware-software design was formally spec-ified in a single language, with encapsulated modular abstraction, interlayer state mappings,and abstract programs relating each layer to those on which it depended [51, 52]. The hard-ware design provided tagged, typed, unforgeable capabilities required for every operation, withidentifiers that were unique for the lifetime of the system. In addition to a few primitive types,application-specific object types could be defined and their properties enforced with the hard-ware assistance provided by the capability-based access controls. The design allowed applica-tion layers to efficiently execute instructions, with object-oriented capability-based addressingdirectly to the hardware – despite appearing at a much higher layer of abstraction in the designspecifications.

Capsicum Capsicum is a lightweight OS capability and sandbox framework included inFreeBSD 9.x and later [76, 75]. Capsicum extends (rather than replaces) UNIX APIs, and pro-vides new kernel primitives (sandboxed capability mode and capabilities) and a userspace sand-box API. These tools support compartmentalization of monolithic UNIX applications into log-ical applications, an increasingly common goal supported poorly by discretionary and manda-tory access controls. This approach was demonstrated by adapting core FreeBSD utilities andGoogle’s Chromium web browser to use Capsicum primitives; it showed significant simplic-ity and robustness benefits to Capsicum over other confinement techniques. Capsicum bothprovides both inspiration and motivation for CHERI: its hybrid capability-system model istransposed into the ISA to provide compatibility with current software designs, and its demandfor finer-grained compartmentalization motivations CHERI’s exploration of more scalable ap-proaches.

1.6.5 A Fresh Opportunity for CapabilitiesDespite an extensive research literature exploring the potential of capability-system approaches,and limited transition to date, we believe that now is the time to revisit these ideas, albeit

24

through the lens of contemporary problems and with insight gained through decades of re-search into security and systems design. As described earlier in the chapter, a transformedthreat environment deriving from ubiquitous computing and networking, and the practical re-ality of widespread exploitation of software vulnerabilities, provides a strong motivation toinvestigate improved processor foundations for software security. This change in environmenthas coincided with improved hardware prototyping techniques and higher-level hardware def-inition languages that facilitate academic hardware-software system research at larger scaleswithout which we would have been unable to explore the CHERI approach in such detail.Simultaneously, our understanding of operating-system and programming-language securityhas been vastly enhanced by several decades of research, and recent development of the hy-brid capability-system Capsicum model suggests a strong alignment between capability-basedtechniques and successful mitigation approaches that can be translated into processor designchoices.

1.7 PublicationsAs our approach has evolved, and project developed, we have published a number of papersand reports describing aspects of the work. The revisiting of capability-based approaches isdescribed in Capabilities Revisied: A Holistic Approach to Bottom-to-Top Assurance of Trust-worthy Systems, published at the Layered Assurance Workshop (LAW 2010) [53], shortly afterthe inception of the project. Mid-way through creation of both the BERI prototyping platform,and CHERI ISA model, we published CHERI: a research platform deconflating hardwarevirtualization and protection at the Workshop on Runtime Environments, Systems, Layeringand Virtualized Environments (RESoLVE 2012) [74]. Most recently, we have published TheCHERI capability model: Revisiting RISC in an age of risk at the International Symposium onComputer Architecture (ISCA 2014) [82].

We have additionally prepared a number of technical reports, including this document, de-scribing our approach and prototypes. To date, this includes the CHERI Instruction-Set Archi-tecture [79], the CHERI User’s Guide [78], the BERI Hardware Reference [80], and the BERISoftware Reference [77]. Further research publications and technical reports on the topics ofthe CHERI hardware-software security model, compiler approaches, and applications of formalmethods will be forthcoming.

1.8 Version HistoryThis report was previously made available as the CHERI Architecture Document, but is nowthe CHERI Instruction-Set Architecture.

1.0 This first version of the CHERI architecture document was prepared for a six-month deliv-erable to DARPA. It included a high-level architectural description of CHERI, motiva-tions for our design choices, and an early version of the capability instruction set.

1.1 The second version was prepared in preparation for a meeting of the CTSRD ExternalOversight Group (EOG) in Cambridge during May 2011. The update followed a week-long meeting in Cambridge, UK, in which many aspects of the CHERI architecture wereformalized, including details of the capability instruction set.

25

1.2 The third version of the architecture document came as the first annual reports from theCTSRD project were in preparation, including a decision to break out formal-methodsappendices into their own CHERI Formal Methods Report for the first time. With anin-progress prototype of the CHERI capability unit, we significantly refined the CHERIISA with respect to object capabilities, and matured notions such as a trusted stack andthe role of an operating system supervisor. The formal methods portions of the documentwas dramatically expanded, with proofs of correctness for many basic security properties.Satisfyingly, many ‘future work’ items in earlier versions of the report were becomingcompleted work in this version!

1.3 The fourth version of the architecture document was released while the first functionalCHERI prototype was in testing. It reflects on initial experiences adapting a microker-nel to exploit CHERI capability features. This led to minor architectural refinements,such as improvements to instruction opcode layout, some additional instructions (suchas allowing CGetPerms retrieve the unsealed bit), and automated generation of opcodedescriptions based on our work in creating a CHERI-enhanced MIPS assembler.

1.4 This version updated and clarified a number of aspects of CHERI following a prototypeimplementation used to demonstrate CHERI in November 2011. Changes include up-dates to the CHERI architecture diagram; replacement of the CDecLen instruction withCSetLen, addition of a CMove instruction; improved descriptions of exception genera-tion; clarification of the in-memory representation of capabilities and byte order of per-missions; modified instruction encodings for CGetLen, CMove, and CSetLen; specifica-tion of reset state for capability registers; and clarification of the CIncBase instruction.

1.5 This version of the document was produced almost two years into the CTSRD project.It documented a significant revision to the CHERI ISA, which was motivated by ourefforts to introduce C-language extensions and compiler support for CHERI, with im-provements resulting from operating system-level work and restructuring the Bluespechardware specification to be more amenable to formal analysis. The ISA, programminglanguage, and operating system sections were significantly updated.

1.6 This version made incremental refinements to version 2 of the CHERI ISA, and also intro-duced early discussion of the CHERI2 prototype.

1.7 Roughly two and a half years into the project, this version clarified and extended documen-tation of CHERI ISA features such as CCall/CReturn and its software emulation, Per-mit Set Type, the CMove pseudo-op, new load-linked and instructions for store-conditionalrelative to capabilities, and several bug fixes such as corrections to sign extension forseveral instructions. A new capability-coprocessor cause register, retrieved using a newCGetCause, was added to allow querying information on the most recent CP2 exception(e.g., bounds-check vs type-check violations); priorities were provided, and also clarifiedwith respect to coprocessor exceptions vs. other MIPS ISA exceptions (e.g., unalignedaccess). This was the first version of the CHERI Architecture Document released to earlyadopters.

1.8 Less three and a half years into the project, this version refined the CHERI ISA based onexperience with compiler, OS, and userspace development using the CHERI model. To

26

improve C-language compatibility, new instructions CToPtr and CFromPtr were defined.The capability permissions mask was extended to add user-defined permissions. Clarifi-cations were made to the behavior of jump/branch instructions relating to branch-delayslots and the program counter. CClearTag simply cleared a register’s tag, not its value.A software-defined capability-cause register range was made available, with a new CSet-Cause instruction letting software set the cause for testing or control-flow reasons. NewCCheckPerm and CCheckType instructions were added, letting software object methodsexplicitly test for permissions and the types of arguments. TLB permission bits wereadded to authorize use of loading and storing tagged values from pages. New CGetDe-fault and CSetDefault pseudo-ops have become the preferred way to control MIPS ISAmemory access. CCall/CReturn calling conventions were clarified; CCall now pushesthe incremented version of the program counter, as well as stack pointer, to the trustedstack.

1.9 - UCAM-CL-TR-850 The document was renamed from the CHERI Architecture Docu-ment to the CHERI Instruction-Set Architecture. This version of the document was madeavailable as a University of Cambridge Technical Report. The high-level ISA descriptionand ISA reference were broken out into separate chapters. A new rationale chapter wasadded, along with more detailed explanations throughout about design choices. Noteswere added in a number of places regarding non-MIPS adaptations of CHERI and 128-bit variants. Potential future directions, such as capability cursors, are discussed in moredetail. Further descriptions of the memory-protection model and its use by operatingsystems and compilers was added. Throughout, content has been updated to reflect morerecent work on compiler and operating-system support for CHERI. Bugs have been fixedin the specification of the CJR and CJALR instructions. Definitions and behavior foruser-defined permission bits and OS exception handling have been clarified.

1.9 Document StructureThis document is an introduction to, and reference manual for, the CHERI instruction-set ar-chitecture:

Chapter 1 introduces CHERI: its motivations, goals, context, philosophy, and design.

Chapter 2 provides a detailed description of the CHERI architecture, including its registerand memory capability models, new instructions, procedure capabilities, and use of message-passing primitives.

Chapter 3 describes the CHERI capability coprocessor, its register file, tagged memory, andother ISA-related semantics.

Chapter 4 provides a detailed description of each new CHERI instruction, its pseudo-operations,and how compilers should handle floating-point loads and stores via capabilities.

Chapter 6 discusses the programming language and operating system implications of CHERI,including its impact on operating-system kernels, language runtimes, and compilers.

Chapter 7 discusses our short- and long-term plans for the CHERI architecture, consideringboth our specific plans and open research questions that must be answered as we proceed.

27

Future versions of this document will continue to expand our consideration of the CHERIinstruction-set architecture and its impact on software, as well as evaluation strategies andresults. Additional information on our CHERI hardware and software implementations, aswell as formal methods work, may be found in accompanying reports.

28

Chapter 2

CHERI Architecture

In this chapter we discuss the high-level design for the CHERI instruction-set architecture (ISA)and consider both the semantics and mechanism of CHERI’s memory and object capabilities.We discuss CHERI in relative isolation from the general-purpose ISA, as our approach mightreasonably apply to a number of RISC ISAs (e.g., including MIPS and ARM), but potentiallyalso to CISC ISAs (such as Intel and AMD 32-bit and 64-bit ISAs).1 In Chapter 3, we considerin detail an instantiation of the CHERI model in an extension to the 64-bit MIPS ISA.

2.1 Design GoalsAs described in Chapter 1, the key observation motivating the CHERI design is that page-oriented virtual memory, nearly universal in commodity CPUs, is neither an efficient nora programmer-friendly primitive for fine-grained memory protection or scalable hardware-supported compartmentalization. Virtual addressing, implemented by a memory managementunit (MMU) and translation look-aside buffer (TLB), clearly plays an important role by dis-associating physical memory allocation and address-space management, facilitating softwarefeatures such as strong separation, OS virtualization, and virtual-memory concepts such asswapping and paging. However, with a pressing need for scalable and fine-grained separation,the overheads and programmability difficulties imposed by virtual addressing as the sole prim-itive for hardware isolation actively deter employment of the principle of least privilege. Theseconcerns translate into three high-level security design goals for CHERI:

1. Management of security context must be a “fast path” that avoids expensive operationssuch as TLB entry invalidation, frequent ring transitions, and cache-busting OS supervi-sor paths. This is a natural consequence of the integral role security functions (such ascreation, refinement, and delegation of memory and object rights) play in fine-grainedcompartmentalized code.

1One idea we have considered is that CHERI-like semantics might be accomplished through extensions toGoogle’s Native Client ISA [85], which uses a strict and statically analyzable subset of Intel and ARM ISAs toensure memory safety. An exciting possibility is that we might extend the LLVM intermediate representation [36]to capture notions of segmentation and capability protection, in which case either NaCl or CHERI back ends mightbe targeted as underlying execution substrates. This naturally raises the question, “why new hardware” – one thatwe have constantly in mind, and believe will be constructively answerable in terms of functionality, performance,and formal assurances.

29

2. Security domain switches must be inexpensive and efficient, with cost scaling linearlywith the number of switches and actual code/data footprint (and hence general-purposecache performance), rather than scaling as a product of the number of security domainsand controlled objects regardless of code and data cache footprints. CHERI is intendedto support at least two orders of magnitude more active security domains per CPU thancurrent MMU-based systems (going from tens or hundreds to at least tens of thousandsof domains).

3. Security domain switches must allow shared object namespaces that provide a unifiedview that connotes both efficient and programmer-comprehensible delegation. Compart-mentalized applications should able to be programmed and debugged without unneces-sary recourse to distributed-system methodology.

These security goals, combined with observations about TLB performance and a desire tocompartmentalize existing single-address-space applications, led us to the conclusion that newinstruction set primitives for memory and object control within an address space would usefullycomplement existing address-space-based separation. In this view, security state associatedwith a thread should be captured as a set of registers that can be explicitly managed by code, andbe preserved and restored cheaply on either side of security domain transitions – in effect, partof a thread’s register file. In the parlance of contemporary CPU and OS design, this establishesa link between hardware threads (OS threads) and security domains, rather than address spaces(OS processes) and security domains.

Because we wish to consider delegation of memory and object references within an addressspace as a first-class operation, we choose to expose these registers to the programmer (or,more desirably, the compiler) so that they can be directly manipulated and passed as arguments.Previous systems built along these principles have been referred to as capability systems, a termthat also usefully describes CHERI.

CHERI’s capability model represents an explicit capability system, in which common capa-bility manipulation operations are unprivileged instructions and transfer of control to a super-visor during regular operations is avoided. In historic capability systems, microcode (or eventhe operating system) was used to implement complex capability operations, some of whichwere privileged. In contemporary RISC CPU designs, the intuitive functional equivalent hasan exception that triggers the supervisor. However, entrance to a supervisor usually remainsan expensive operation, and hence one to avoid in high-performance paths. In keeping withthe RISC design philosophy, we are willing to delegate significant responsibility for safety tothe compiler and run-time linker to minimize hardware knowledge of higher-level languageconstructs.

CHERI capabilities may refer to regions of memory, with bounded memory access (as insegments). Memory capabilities will frequently refer to programmer-described data structuressuch as strings of bytes, structures consisting of multiple fields, and entries in arrays, althoughthey might also refer to larger extents of memory (e.g., the entire address space). While com-patibility features in the CHERI ISA allow programmers to continue to use pointers in legacycode, we anticipate that capabilities will displace pointer use as code is migrated to CHERIcode generation, providing stronger integrity for data references, bounds checking, permissionchecking, and so on. In our prototype extensions to the C language, programmers can explicitlyrequest that capabilities be used instead of pointers, providing stronger protection, or in somecases rely on the compiler to automatically generate capability-aware code – for example, when

30

code accessing the stack is compiled with a suitable application binary interface (ABI). We areexploring further static analysis and compilation techniques that will allow us to automate de-ployment of capability-aware code to a greater extent, minimizing disruption of current sourcecode while allowing programs to experience protection improvements.

Alternatively, capabilities may refer to objects that can be invoked, which allows the im-plementation of protected subsystems – i.e., services that execute in a security domain otherthan the caller’s. At the moment of object invocation, caller capabilities are sealed to protectthem from inappropriate use by the callee, and the invoked object is unsealed to allow theobject callee to access private resources it requires to implement its services. The caller andcallee experience a controlled delegation of resources across object invocation and return. Forexample, the caller might delegate access to a memory buffer, and the callee might then writea Unicode string to the buffer describing the contents of the protected object, implementingcall-by-reference.2 A key goal has been to allow capabilities passed across protection-domainboundaries to refer to ordinary C data on the stack or heap, allowing easier adaptation of exist-ing programs and libraries to use CHERI’s features. The semantics of capabilities are discussedin greater detail later in this and the following chapter.

2.2 A Hybrid Capability-System ArchitectureDespite our complaints about the implications of virtual addressing for compartmentalization,we feel that virtual memory is a valuable hardware facility: it provides a strong separationmodel; it makes implementing facilities such as swapping and paging easier; and by virtue ofits virtual layout, it can significantly improve software maintenance and system performance.CHERI therefore adopts a hybrid capability-system model: we retain support for a commodityvirtual-memory model, implemented using an MMU with a TLB, while also introducing newprimitives to permit multiple security domains within address spaces (Figure 2.1). Each addressspace becomes its own decomposition domain, within which protected subsystems can interactusing both hierarchical and non-hierarchical security models. In effect, each address space isits own virtual capability machine.

To summarize our approach, CHERI draws on two distinct, and previously uncombined,designs for processor architecture:

• Page-oriented virtual memory systems allow an executive (often the operating systemkernel) to create a process abstraction via the MMU. In this model, the kernel is respon-sible for maintaining separation using this relatively coarse tool, and then providing sys-tem calls that allow spanning process isolation, subject to access control. Systems suchas this make only weak distinctions between code and data, and in the mapping fromprogramming language to machine code discard most typing and security information.

• Capability systems, often based on a single global address space, map programming-language type information and protection constraints into instruction selection. Code atany given moment in execution exists in a protection domain consisting of a dynamic set

2CHERI does not implement implicit rights amplification, a property of some past systems including HYDRA.Callers across protected subsystem boundaries may choose to pass all rights they hold, but it is our expectationthat they will generally not do so – otherwise, they would use regular function calls within a single protectedsubsystem.

31

Hybrid code blending general-purpose registers and capabilities

Legacy application code compiled for general-purpose registers

Per-address space memory management and capability executive

High-assurance "pure" capability code

FreeBSDkernel

w/Capsicum

Kernel address space executive

Devicedrivers

Networkstack

Chromiumweb browser

JavaScript

Separation kernel

C++ RTPure capability C, Objective-C,

or OCamlUnikernellibc executive libc executive

CHERI

Unikernel executive

Capa

bility

-sys

tem

add

ress

spa

ces

Separation kernel executive

Fetch

libc executive

Capability C, Objective-C, or OCaml UNIX application

zlib

FreeBSDkernel

w/Capsicum

Kernel VM and allocator

Networkstack

Xen hypervisor

libc malloc

Commodity CPU

Virtu

al a

ddre

ss s

pace

s su

ppor

ted

by p

aged

VM

Fetch

zlib

Chromiumweb browser

JavaScript

C++ RT

libc malloc

Devicedrivers

Figure 2.1: CHERI’s hybrid capability architecture: initially, legacy software components ex-ecute without capability awareness, but security-sensitive TCB elements or particularly riskycode bases are converted. In the long term, all packages are converted, implementing leastprivilege throughout the system.

of rights whose delegation is controlled by the flow of code. (These instantaneous rightsare sometimes referred to as spheres of protection in the operating system and securityliterature.) Such a design generally offers greater assurance, because the principle ofleast privilege can be applied at a finer granularity.

Figure 2.1 illustrates the following alternative ways in which the CHERI architecture mightbe used. In CHERI, even within an address space, existing and capability-aware code canbe hybridized, as reads and writes via general-purpose MIPS registers are automatically in-directed through a reserved capability register before being processed by the MMU. This al-lows a number of interesting compositions, including the execution of capability-aware, andhence significantly more robust, libraries within a legacy application. Another possibility is acapability-aware application running one or more instances of capability-unaware code withinsandboxes, such as legacy application components or libraries – effectively allowing the trivialimplementation of the Google Native Client model.

Finally, applications can be compiled to be fully capability-aware, i.e., able to utilize thecapability features for robustness and security throughout their structure. The notion of acapability-aware executive also becomes valuable – likely as some blend of the run-time linkerand low-level system libraries (such as libc): the executive will set up safe linkage betweenmutually untrusting components (potentially with differing degrees of capability support, andhence differing ABIs), and ensure that memory is safely managed to prevent memory-reusebugs from escalating to security vulnerabilities.3 Useful comparison might also be made be-tween our notion of an in-address-space executive and a microkernel, as the executive will

3Similar observations about the criticality of the run-time linker for both security and performance in capabilitysystems have been made by Karger [30].

32

similarly take responsibility for configuring protection and facilitating controlled sharing ofdata. As microkernels are frequently capability-based, we might find that not only are ideasfrom the microkernel space reusable, but also portions of their implementations. This is anexciting prospect, especially considering that significant effort has been made to apply formalverification techniques to microkernels.

2.3 The CHERI Software Stack

The notion of hybrid design is key to our adoption argument: CHERI systems are able to exe-cute today’s commodity operating systems and applications with few modifications. Use of ca-pability features can then be selectively introduced in order to raise confidence in the robustnessand security of individual system components, which are able to fluidly interact with other un-enhanced components. This notion of hybrid design first arose in Cambridge’s Capsicum [76](which blends the POSIX Application Programming Interface (API), as implemented in theFreeBSD operating system) with a capability design by allowing processes to execute in hy-brid mode or in capability mode. Traditional POSIX code can run along side capability-modeprocesses, allowing the construction of sandboxes; using a capability model, rights can be del-egated to these sandboxes by applications that embody complex security policies. One suchexample from our USENIX Security 2010 Capsicum paper [76] is the Chromium web browser,which must map the distributed World Wide Web security model into local OS containmentprimitives.

CHERI’s software stack will employ hybrid design principles from the bottom up: capability-enhanced separation kernels will be able to implement both conventional virtual-machine in-terfaces to guest operating systems, or directly host capability-aware operating systems or ap-plications, ensuring robustness. This would provide an execution substrate on which both com-modity systems built on traditional RISC instruction models (such as FreeBSD) can run sideby side with a pure capability-oriented software stack, such as capability-adapted languageruntimes. Further, CheriBSD, a CHERI-enhanced version of the FreeBSD operating system,and its applications, will be able to employ CHERI features in their own implementations. Forexample, key data-processing libraries, such as image compression or video decoding, mightuse CHERI features to limit the impact of programming errors through fine-grained memoryprotection, but also apply compartmentalization to mitigate logical errors through the principleof least privilege. We have extended the existing Clang/LLVM compiler suite to support C-language extensions for capabilities, allowing current code to be recompiled to use capabilityprotections based on language-level annotations, but also to link against unmodified code.

To this end, the CHERI ISA design allows software context to address memory either vialegacy MIPS ISA load and store instructions, which implicitly indirect through a reserved ca-pability register configurable by software, or via new capability load and store instructions thatallow the compiler to explicitly name the object to be used. In either case, access is permittedto memory only if it is authorized by a capability that is held in the register file (or, by transitiv-ity, any further capability that can be retrieved using those registers and the memory or objectsthat it can reach). New ABIs and calling conventions are defined to allow transition between(and across) CHERI-ISA and MIPS-ISA code to allow legacy code to invoke capability-awarecode, and vice versa. For example, in this model CheriBSD might employ capability-orientedinstructions in the implementation of risky data manipulations (such as network-packet pro-

33

cessing), while still relying on traditionally written and compiled code for the remainder ofthe kernel. Similarly, within the Chromium web browser, the JavaScript interpreter might beimplemented in terms of capability-oriented instructions to offer greater robustness, while theremainder of Chromium would use traditional instructions.

One particularly interesting property of our hardware design is that capabilities can take ondifferent semantics within different address spaces, with each address-space’s executive inte-grating memory management and capability generation. In the CheriBSD kernel, for example,virtual addressing and capability use can be blended; the compiler and kernel memory allocatorcan use capabilities for certain object types, but not for others. In various userspace processes,a hybrid UNIX / C runtime might implement limited pools of capabilities for specially com-piled components, but another process might use just-in-time (JIT) compilation techniques tomap Java bytecode into CHERI instructions, offering improved performance and a significantlysmaller and stronger Java TCB.

Capabilities supplement the purely hierarchical ring model with a non-hierarchical mecha-nism – as rings support traps, capabilities support protected subsystems. One corollary is thatthe capability model could be used to implement rings within address spaces. This offers someinteresting opportunities, not least the ability to implement purely hierarchical models wheredesired; for example, a separation kernel might use the TLB to support traditional OS instances,but only capability protections to constrain an entirely capability-based OS. A further extremeis to use the TLB only for paging support, and to implement a single-address-space operatingsystem as envisioned by the designers of many historic capability systems.

This hybrid view offers a vision for a gradual transition to stronger protections, in whichindividual libraries, applications, and even whole operating systems can incrementally adoptstronger hardware memory protections without sacrificing the existing software stack. Discus-sion of these approaches also makes clear the close tie between memory-oriented protectionschemes and the role of the memory allocator, an issue discussed in greater depth later in thischapter.

2.4 Capability Model

Chapter 3 provides detailed documentation of the registers, capabilities, and new instructionscurrently defined in CHERI. These concepts are briefly introduced here.

2.4.1 Capabilities are for Compilers

Throughout, we stress the distinction between the notion of the hardware security model and theprogramming model; unlike in historic CISC designs, and more in keeping with historic RISCdesigns, CHERI instructions are intended to support the activities of the compiler, rather thanbe directly programmed by application authors. While there is a necessary alignment betweenprogramming language models for computation (and in the case of CHERI, security) and thehardware execution substrate, the purpose of CHERI instructions is to make it possible for thecompiler to cleanly and efficiently implement higher-level models, and not implement themdirectly. As such, we differentiate the idea of a hardware capability type from a programminglanguage type – the compiler writer may choose to conflate the two, but this is an option ratherthan a requirement.

34

2.4.2 Capabilities

Capabilities are unforgeable tokens of authority through which programs access all memoryand services within an address space. Capabilities may be held in capability registers, wherethey can be manipulated or dereferenced using capability coprocessor instructions, or in mem-ory. Capabilities themselves may refer to memory (unsealed capabilities) or objects (sealedcapabilities). Memory capabilities are used as arguments to load and store instructions, to ac-cess either data or further capabilities. Object capabilities may be invoked to transition betweenprotection domains using call and return instructions.

Unforgeability is implemented by two means: tag bits and controlled manipulation. Eachcapability register, and each capability-aligned physical memory location, is associated witha tag bit indicating that a capability is valid. Attempts to directly overwrite a capability inmemory using data instructions automatically clear the tag bit. When data is loaded into acapability register, its tag bit is also loaded; while data without a valid tag can be loaded into acapability register, attempts to dereference or invoke such a register will trigger an exception.

Controlled manipulation is enforced by virtue of the ISA: instructions that manipulate ca-pability register fields (e.g., base, length, permissions, type) are not able to increase the rightsassociated with a capability. Similarly, sealed capabilities can be unsealed only via the invo-cation mechanism, or via the unseal instruction subject to similar monotonicity rules. Thisenforces encapsulation, and prevents unauthorized access to the internal state of objects.

We anticipate that many languages will expose capabilities to the programmer via pointersor references – e.g., as qualified pointers in C, or mapped from object references in Java. Ingeneral, we expect that languages will not expose capability registers to management by pro-grammers, instead using them for instruction operands and as a cache of active values, as is thecase for general-purpose registers today. On the other hand, we expect that there will be someprogrammers using the equivalent of assembly-language operations, so that system securitycannot rely solely on the goodness of compilers.

2.4.3 Capability Registers

CHERI supplements the 32 general-purpose, per-hardware thread registers provided by theMIPS ISA with 32 additional capability registers. Where general-purpose registers describethe computation state of a software thread, capability registers describe its instantaneous rightswithin an address space. A thread’s capabilities potentially imply a larger set of rights, whichmay be loaded via held capabilities, which may notionally be considered as the protectiondomain of a thread.

There are also several implicit capability registers associated with each hardware thread,including a memory capability that corresponds to the instruction pointer, and capabilities usedduring exception handling. This is structurally congruent to implied registers and system con-trol coprocessor (CP0) registers found in the base MIPS ISA.

Each capability register has 256 bits; unlike general-purpose registers, capability registersare structured, and contain a number of fields with defined semantics and constrained values:

Sealed bit If the sealed bit is unset, the capability describes a memory segment that is accessi-ble via load and store instructions. If it is set, the capability describes an object capability,which can be accessed only via object invocation.

35

Permissions The permissions mask controls operations that may be performed using the ca-pability.

Object type / entry address Notionally the object type, used to ensure that correspondingcode and data capabilities for the object are used together correctly.

Base This is the base address of a memory region.

Length This defines the length of a memory region.

Reserved fields These bits are reserved for future experimentation.

Tag bit The tag bit is not part of the base 256 bits. It indicates whether or not the capabilityregister holds a valid capability; this allows non-capability values to be moved via ca-pability registers, making it possible to implement software functions that, for example,copy memory oblivious to capabilities being present.

We have discussed a number of schemes to reduce overhead implied by the quite sizablecapability register file. 32 registers is nicely symmetric with the MIPS ISA, but in practiceleads to a substantial overhead; we have considered reducing the number to 16 or even 8 toreduce hardware resource, cache footprint, and context-switch time. We have also ponderedschemes to reduce the size of capability registers themselves; simple reduction of the addressesto smaller numbers to 40-bit from 64-bit, reflecting the largest virtual addresses supportable inthe MIPS TLB, might allow reduction to 128-bit. Another approach might be to differentiatelarger object capabilities, which require types, from pure memory capabilities, which could berepresented more compactly, but would require compilers to handle multiple capability sizes.Finally, more complex techniques, such as Low-Fat Pointers [32] might also prove useful.Once again, hardware specifications written in Bluespec allow considerable flexibility and easeof understanding among these options, which will be particularly valuable as we get furtherinto detailed experimentation, simulation, and modeling.

Object invocation is a central operation in the CHERI ISA, as it implements protectedsubsystem domain transitions that atomically update the set of rights (capabilities) held bya hardware thread, and that provide a trustworthy return path for later use. When an objectcapability is invoked, its data and code capabilities are unsealed to allow access to per-objectinstance data and code execution. Rights may be both acquired and dropped on invocation,allowing non-hierarchical security models to be implemented. Strong typing and type checkingof objects, a notion first introduced in PSOS’s type enforcement, serves functions both at theISA level – providing object atomicity despite the use of multiple independent capabilities todescribe an object – and to support language-level type features. For example, types can beused to check whether additional object arguments passed to a method are as they should be.As indicated earlier, the hardware capability type may be used to support language-level types,but should not be confused with language-level types.

2.4.4 Memory ModelIn the abstract, capabilities are unforgeable tokens of authority. In the most reductionist sense,the CHERI capability namespace is the virtual address space, as all capabilities name (andauthorize) actions on addresses. CHERI capabilities are unforgeable by virtue of capability

36

register semantics and tagged memory, and act as tokens of authority by virtue of memorysegments and object capability invocation.

However, enforcement of uniqueness over time is a property of the software memory allo-cation policy. More accurately, it is a property of virtual address-space allocation and reuse,which rests in a memory model composed from the capability mechanism, virtual address spaceconfiguration, and software language-runtime memory allocation.

This issue has presented a significant challenge in the design of CHERI: how can we providesufficient mechanism to allow memory management, fundamentally a security operation incapability systems, while not overly constraining software runtimes regarding the semanticsthey can implement? Should we provide hardware-assisted garbage collection along the lines ofthe Java Virtual Machine’s garbage collection model? Should we implement explicit revocationfunctionality, along the lines of Redell’s capability revocation scheme (effectively, a level ofindirection for all capabilities, or selectively when the need for revocation is anticipated)?

We have instead opted for dual semantics grounded in the requirements of real-world low-level system software: CHERI lacks a general revocation scheme; however, in coordinationwith the software stack, it can provide for both strict limitations on the extent of hardware-supported delegation periods, and software-supported generalized revocation using interposi-tion. The former is intended to support the brief delegation of arguments from callers to calleesacross object-capability invocation; the latter allows arbitrary object reference revocation at agreater price.

2.4.5 Ephemeral Capabilities and Revocation

To this end, capabilities may be further tagged as ephemeral, which allows them to be processedin registers, stored in constrained memory regions, and passed on via invocation of other ob-jects. The goal of capability ephemerality is to introduce a limited form of revocation that isappropriate for temporary delegation across protected subsystem invocations, which are notpermitted to persist beyond that invocation. Among other beneficial properties, ephemeral ca-pabilities allow the brief delegation of access to arguments passed by reference, such as regionsof the caller’s stack (a common paradigm in C language programming).

In effect, ephemeral capabilities inspire a single-bit information-flow model, bounding thepotential spread of capabilities for ephemeral objects to capability registers and limited portionsof memory. The desired protection property can be enforced through appropriate memorymanagement by the address-space executive: that is, ephemeral capabilities can be limited to aparticular thread, with bounded delegation time down the (logical) stack.4

Generalized revocation is not supported directly by the CHERI ISA; instead, we rely onthe language runtime to implement either a policy of virtual address non-reuse or garbagecollection. A useful observation is that address space non-reuse is not the same as memory non-reuse: the meta-data required to support sparse use of a 64-bit address space scales with actualallocation, rather than the span of consumed address space. For many practical purposes, a 64-bit address space is virtually infinite5, so causing the C runtime to not reuse address space is now

4It has been recommended that we substitute a generalized generation count-based model for an informationflow model. This would be functionally identical in the ephemeral capability case, used to protect per-stack data.However, it would also allow us to implement protection of thread-local state, as well as garbage collection, ifdesired. The current ISA does not yet reflect this planned change.

5As is 640K of memory. It has also not escaped our notice that there is a real OS cost to maintaining the

37

a realistic option. Software can, however, make use of interposition to implement revocation orother more semantically rich notions of privilege narrowing, as proposed in HYDRA.

2.4.6 Notions of PrivilegeIn operating-system design, privileges are a special set of rights exempting a component fromthe normal protection and access-control models – perhaps for the purposes of system boot-strapping, system management, or low-level functionality such as direct hardware access. InCHERI, three notions of privilege are defined – two in hardware, and a new notion of privilegein software relating to the interactions of capability security models between rings.

Ring-based privilege is derived from the commodity hardware notion that a series of suc-cessively higher-level rings provides progressively fewer rights to manage hardware protectionfeatures, such as TLB entries – and consequently potentially greater integrity, reliability, andresilience overall (as in Multics). Attempts to perform privileged instructions will trap to alower ring level, which may then proceed with the operation, or reject it. CHERI extends thisnotion of privilege into the new capability coprocessor, authorizing certain operations basedon the ring in which a processor executes, and potentially trapping to the next lower ring if anoperation is not permitted. The trap mechanism itself is modified in CHERI, in order to saveand restore the capability register state required within the execution of each ring – to authorizeappropriate access for the trap handler.

Hardware capability context privilege is a new notion of privilege that operates within rings,and is managed by the capability coprocessor. When a new address space is instantiated, codeexecuting in the address space is provided with adequate initial capabilities to fully manage theaddress space, and derive any required capabilities for memory allocation, code linking, andobject-capability type management. In CHERI, all capability-related privileges are capturedby capabilities, and capability operations never refer to the current processor ring to authorizeoperations, although violation of a security property (i.e., an attempt to broaden a memorycapability) will lead to a trap, and allow a software supervisor in a lower ring to provide al-ternative semantics. This approach follows the spirit of Paul Karger’s paper on limiting thedamage potential of discretionary Trojan horses [28], and extends it further.

Supervisor-enforced capability context privilege is a similar notion of privilege that mayalso be implemented in software trap handlers. For example, an operating system kernel maychoose to accept system-call traps only from appropriately privileged userspace code (e.g.,by virtue of holding a capability with full access to the userspace address space, rather thanjust narrow access, or that has a reserved user-defined permission bit set), and therefore cancheck the capability registers of the saved context to determine whether the trap was from anappropriate execution context. This might be used to limit system call invocation to a specificprotected subsystem that imposes its own authorization policy on application components bysafely wrapping system calls from userspace.

2.4.7 Traps, Interrupts, and Exception HandlingAs in MIPS, traps and interrupts remain the means by which ring transitions are triggered inCHERI. They are affected in a number of ways by the introduction of capability features:

abstraction of virtual memory; one merit to our approach is that it will deemphasize the virtual memory as aprotection system, potentially reducing that overhead.

38

New exceptions New exception opportunities are introduced for both existing and new in-structions, which may trap if insufficient rights are held, or an invalid operation is requested.For example, attempts to read a capability from memory using a capability without the readcapability permission will trigger a trap.

Reserved capability registers for exception handling New exception-handling functional-ity is required to ensure that exception handlers themselves can execute properly. We reserveseveral capability registers for use both by the exception-handling mechanism itself (describingthe rights that the exception handler will run with) and for use by software exception handlers(a pair of reserved registers that can be used safely during context switching). This approachis not dissimilar from the current notion of exception-handling registers in the MIPS ABI,which reserves two general-purpose registers for this purpose. However, whereas the MIPSABI simply dictates that user code cannot rely on the two reserved exception registers beingpreserved, CHERI requires that access is blocked, as capability registers delegate rights andalso hold data. We currently grant access to exception-related capability registers by virtue ofspecial permission bits on the capability that describe the currently executing code; attemptingto access reserved registers without suitable permission will trigger an exception.

Saved program-counter capability Exception handlers must also be able to inspect excep-tion state; for example, as PC, the program counter, is preserved today in a control register,EPC, the program counter capability must be preserved as EPCC so that it can be queried.

Implications for pipelining Another area of concern in the implementation is the interactionbetween capability registers and pipelining. Normally, writing to TLB control registers in CP0occurs only in privileged rings, and the MIPS ISA specifies that a number of no-op instructionsfollow TLB register writes in order to flush the pipeline of any inconsistent or intermediateresults. Capability registers, on the other hand, may be modified from unprivileged code, whichcannot be relied upon to issue the required no-ops. This case can be handled through thesquashing of in-flight instructions, which may add complexity to pipeline processing becauseincorrect handling could otherwise lead to serious vulnerabilities.

2.4.8 Tagged MemoryAs with general-purpose registers, storage capability register values in memory is desirable– for example, to push capabilities onto the stack, or manipulate arrays of capabilities. Tothis end, each capability-aligned and capability-sized word in memory has an additional tagbit. The bit is set whenever a capability is atomically written from a register to an authorizedmemory location, and cleared if a write occurs to any byte in the word using a general-purposestore instruction. Capabilities may be read only from capability-aligned words, and only if thetag bit is set at the moment of load; otherwise, a capability load exception is thrown. Tagsare associated with physical memory locations, rather than virtual ones, such that the samememory mapped at multiple points in the address space, or in different address spaces, willhave the same tags.

Tags require strong coherency with the data they protect, and it is expected that tags will becached with the memory they describe within the cache hierarchy. Strong atomicity propertiesare required such that it is not possible to partially overwrite a capability value in memory while

39

retaining the tag. This proves a set of properties that falls out naturally from current coherentmemory-subsystem designs.

Additional bits are present in TLB entries to indicate whether a given memory page is con-figured to have capabilities loaded or stored for the pertinent address space identifier (ASID).For example, this allows the kernel to set up data sharing between two address spaces withoutpermitting capability sharing (which, as capability interpretation is scoped to address spaces,might lead to undesirable security or programmability properties). Special instructions allowthe supervisor to efficiently extract and set tag bits for ranges of words within a page for the pur-pose of more easily implemented paging of capability memory pages. Use of these instructionsis conditioned on notions of ring and capability context privilege.

2.4.9 Capability Instructions

Various newly added instructions are documented in detail in Chapter 3. Briefly, these in-structions are used to load and store via capabilities, load and store capabilities themselves,manage capability fields, invoke object capabilities, and create capabilities. Where possible,the structure and semantics of capability instructions have been aligned with similar core MIPSinstructions, similar calling conventions, and so on. The number of instructions has also beenminimized to the extent possible.

2.4.10 Object Capabilities

As noted above, the CHERI design calls for two forms of capabilities: capabilities that describeregions of memory and offer bounded-buffer “segment” semantics, and object capabilities thatpermit the implementation of protected subsystems. In our model, object capabilities are repre-sented by a pair of sealed code and data capabilities, which provide the necessary informationto implement a protected subsystem domain transition. Object capabilities are “invoked” usingthe CCall instruction (which is responsible for unsealing the capabilities, performing a safesecurity-domain transition, and argument passing), followed by CReturn (which reverses thisprocess and handles return values).

In traditional capability designs, invocation of an object capability triggered microcoderesponsible for state management. Initially, we have implemented CCall and CReturn as soft-ware exception handlers in the kernel, but are now exploring optimizations in which CCall andCReturn perform a number of checks and transformations to minimize software overhead. Inthe longer term, we hope to investigate the congruence of object-capability invocation withmessage-passing primitives between hardware threads: if each register context represents a se-curity domain, and one domain invokes a service offered by another domain, passing a smallnumber of general-purpose and capability registers, then message passing may offer a way toprovide significantly enhanced performance.6 In this view, hardware thread contexts, or registerfiles, are simply caches of thread state to be managed by the processor.

6This appears to be another instance of the isomorphism between explicit message passing and shared memorydesign. If we introduce hardware message passing, then it will in fact blend aspects of both models and use theexplicit message-passing primitive to cleanly isolate the two contexts, while still allowing shared arguments usingpointers to common storage, or delegation using explicit capabilities. This approach would allow applicationdevelopers additional flexibility for optimization.

40

Significant questions then arise regarding rendezvous: how can messages be constrained sothat they are delivered only as required, and what are the interactions regarding scheduling?While this structure might appear more efficient than a TLB (by virtue of not requiring objectswith multiple names to appear multiple times), it still requires an efficient lookup structure(such as a TCAM).

In either instantiation, a number of design challenges arise. How can we ensure safe in-vocation and return behavior? How can callers safely delegate arguments by reference forthe duration of the call to bound the period of retention of a capability by a callee (which isparticularly important if arguments from the call stack are passed by reference)?

How should stacks themselves be handled in this light, since a single logical stack willarguably be reused by many different security domains, and it is undesirable that one domainin execution might ‘pop’ rights from another domain off of the stack, or reuse a capability toaccess memory previously used as a call-by-reference argument.

These concerns argue for at least three features: a logical stack spanning many stack frag-ments bound to individual security domains, a fresh source of ephemeral stacks ready for reuse,and some notion of a do-not-transfer facility in order to prevent the further propagation ofa capability (perhaps implemented via a revocation mechanism, but other options are read-ily apparent). PSOS explored similar notions of propagation-limited capabilities with similarmotivations.

Our current software CCall/CReturn maintains a ‘trusted stack’ in the kernel address spaceand provides for reliable return, but it is clear that further exploration is required. Our goal isto support many different semantics as required by different programming languages, from anenhanced C language to Java. By adopting a RISC-like approach, in which traps to a lowerring occur when hardware-supported semantics is exceeded, we will be able to supplement thehardware model through modifications to the supervisor.

2.4.11 Peripheral Devices

As described in this chapter, our capability model is a property of the instruction set architectureof a CHERI CPU, and imposed on code executing on the CPU. However, in most computersystems, Direct Memory Access (DMA) is used by peripheral devices to transfer data into andout of system memory without explicit instruction execution for each byte transferred: devicedrivers configure and start DMA using control registers, and then await completion notificationthrough an interrupt or by polling. Used in isolation, nothing about the CHERI ISA impliesthat device memory access would be constrained by capabilities.

This raises a number of interesting questions. Should DMA be forced to pass through thecapability equivalent of an I/O MMU in order to be appropriately constrained? How mightthis change the interface to peripheral devices, which currently assume that physical addressesare passed to them? Certainly, reuse of current peripheral networking and video devices withCHERI CPUs while maintaining desired security properties is desirable.

For the time being, device drivers continue to hold the privilege to direct DMA to arbi-trary physical memory addresses, although hybrid models – such as allowing DMA only tospecific portions of physical memory – may prove appropriate. Similar problems have plaguedvirtualization in commodity CPUs, where guest operating systems require DMA memory per-formance but cannot be allowed arbitrary access to physical memory. Exploring I/O MMU-likemodels and their integration with capabilities is high on our todo list; one thing is certain, how-

41

ever: a combination of hardware- and software-provided cache and memory management mustensure that tags are suitably cleared when capability-oblivious devices write to memory, inorder to avoid violation of capability integrity properties.

In the longer term, one quite interesting idea is embedding CHERI support in peripheraldevices themselves, to require the device to implement a CHERI-aware TCB that would syn-chronize protection information with the host OS. This type of model appeals to ideas from het-erogeneous computing, and is one we hope to explore in greater detail in the future. Anotheralternative would be to pursue the notion of smart buses used by peripherals – for example,making them capability aware.

42

Chapter 3

Capability Coprocessor

This chapter describes an application of the CHERI approach to the 64-bit MIPS ISA. Newinstructions are implemented as a MIPS coprocessor, coprocessor 2, an encoding space reservedfor ISA extensions. In addition to adding new instructions, some behaviors have been modifiedin CHERI – notably, those of some standard MIPS instructions, TLBs, and exception handling.For example, existing memory load and store instructions are now implicitly indirected througha capability in order to enforce permissions, rebasing, and bounds checking on legacy code.

NOTE: the instruction-set architecture described here is preliminary; we expect to refine itsignificantly as a result of ongoing discussion, hardware prototyping, practical experimentation,and user feedback!

3.1 Capability Registers

Table 3.1 illustrates capability registers defined by the capability coprocessor. CHERI defines28 general-purpose capability registers, which may be named using most capability registerinstructions. These registers are intended to hold the working set of rights required by in-execution code, intermediate values used in constructing new capabilities, and copies of capa-bilities retrieved from EPCC and PCC as part of the normal flow of code execution, whichis congruent with current MIPS-ISA exception handling via coprocessor 0. Four capabilityregisters have special functions and are accessible only if allowed by the permissions field C0.Note that C0 and C27 (IDC) also have hardware-specific functions, but are otherwise general-purpose capability registers.

Each capability register also has an associated tag indicating whether it currently containsa valid capability. Any load and store operations via an invalid capability will trap.

Conventions for Capability Register Use

We are developing a set of ABI conventions regarding use of the other software-managed ca-pability registers similar to those for general-purpose registers: caller-save, callee-save, a stackcapability register, etc.

The current convention used by LLVM makes the following reservations for calls within aprotection domain:

43

Register(s) Description

PCC Program counter capability (PCC); the capability through whichPC is indirected by the processor when fetching instructions.

C0 Capability register through which all non-capability load andstore instructions are indirected. This allows legacy MIPS codeto be controlled using the capability coprocessor.

C1...C23 General-purpose capability registers referenced explicitly bycapability-aware instructions.

RCC (C24) Return code capability; after a CJALR instruction, the previousvalue of PCC is saved in RCC.

C25 General-purpose capability register reserved for use in exceptionhandling.

IDC (C26) Invoked data capability; the capability that was unsealed at thelast protected procedure call. This capability holds the unlimitedcapability at boot time.

KR1C (C27) A capability reserved for use during kernel exception handling.KR2C (C28) A capability reserved for use during kernel exception handling.KCC (C29) Kernel code capability; the code capability moved to PCC when

entering the kernel for exception handling.KDC (C30) Kernel data capability; the data capability containing the security

domain for the kernel exception handler.EPCC (C31) Capability register associated with the exception program counter

(EPC) required by exception handlers to save, interpret, and storethe value of PCC at the time the exception fired.

Table 3.1: Capability registers defined by the capability coprocessor.

44

• C1-C2 are caller-save. During a cross-domain call, these are used to pass the PCC andIDC values, respectively. In the invoked context, they are always available as tempo-raries, irrespective of whether the function was invoked as the result of a cross-domaincall.

• C3-C10 are used to pass arguments and are not preserved across calls. Capability returnsare placed in C3.

• C11-C16 are caller-save registers.

• C17-C24 are callee-save registers.

When calling less-trusted code, there is no guarantee that a non-malicious callee will abideby these conventions. Thus, all registers should be regarded as caller-save. Additionally, allcapability registers that are not part of the explicit argument set should be invalidated usingthe CClearTag instruction. This will prevent leakage of rights to untrustworthy callees. Whererights are explicitly passed to a callee, it may be desirable to clear the non-ephemeral bit whichwill (in a suitably configured runtime) prevent further propagation of the capability. Similarconcerns apply to general-purpose registers, which should be preserved by the caller if theircorrect preservation is important, and cleared if they might leak sensitive data.

Protected Procedure Calls

A protected procedure call, instruction CCall, escapes to a handler which takes a sealed ex-ecutable (“code”) and sealed non-executable (“data”) capability with matching types. If thetypes match, the unsealed code capability is placed in PCC and the unsealed data capability isplaced in IDC. The handler will also push the previous PCC, IDC, PC + 4, and SP to a stackpointed to by TSC. The stack pointer TSC may be implemented either as a hardware registeror as a variable internal to a software implementation of CCall. The caller should invalidate allregisters that are not intended to be passed to the callee before the call.

A protected procedure return, instruction CReturn, also escapes to a handler which popsthe code and data capabilities from the stack at TSC and places them in PCC and IDC re-spectively; it likewise pops PC and SP. The callee should invalidate all registers that are notintended to be passed to the caller before the return.

The caller is responsible for ensuring that its protection domain is entirely embodied in thecapability in IDC so that it can restore its state upon return.

These semantics are software defined, and we anticipate that different operating-system andprogramming-language security models might handle these, and other behaviors, in differentways. For example, in our prototype CheriBSD implementation, the operating-system kernelmaintains a “trusted stack” onto which which values are pushed during invocation, and fromwhich values are popped on return. Over time, we anticipate providing multiple sets of se-mantics, perhaps corresponding to less synchronous domain-transition models, and allowingdifferent userspace runtimes to select (or implement) the specific semantics their programmingmodel requires. This is particularly important in order to provide flexible error handling: if asandbox suffers a fault, or exceeds its execution-time budget, it is the OS and programming lan-guage that will define how recovery takes place, rather than the ISA definition. Basic hardware

45

015163031

perms u

otype/eaddr (64 bits)

base (64 bits)

length (64 bits)

256 bits

Figure 3.1: Contents of a capability

acceleration of capability invocation and return is easy to envision regardless of the specific se-mantic: many of the checks performed against capability permissions and types will be sharedby all of these systems.

Capabilities and Exception Handling

KCC and KDC hold the code capability and data capability which describe the protectiondomain of the system exception handler. When an exception occurs, KCC is moved to PCCand the victim PCC is copied to EPCC so that the exception may return to the correct address.

When an exception handler returns with eret, EPCC is moved into PCC.

3.2 CapabilitiesThe CHERI processor is currently always defined to be big-endian, in contrast to traditionalMIPS, which allows endianness to be selected by the supervisor. Figure 3.1 illustrates theformat of a capability.

Each capability register contains the following fields:

• Tag bit (“tag”, 1 bit)

• Unsealed flag (“u”, 1 bit)

• Permissions mask (“perms”, 31 bits)

• Object type (“otype/eaddr”, 64 bits)

• Base virtual address (“base”, 64 bits)

• Length in bytes (“length”, 64 bits)

46

3.2.1 tagThe tag bit indicates whether a capability register contains a capability or normal data. If tagis set, the register contains a capability. If tag is cleared, the rest of the register contains 256bits of normal data.

3.2.2 uThe u flag indicates whether a capability is usable for general-purpose capability operations.If this flag is cleared, the capability is sealed and it may be used only by a CCall instruction.If the CCall instruction receives a sealed executable capability and a sealed non-executablecapability with matching otype/eaddr fields, both capabilities will have their u flag set andwill be made available in the next cycle, thus entering a new security domain.

3.2.3 permsThe 31-bit perms bit vector governs the permissions of the capability including read, writeand execute permissions. The contents of this field are listed in table 3.2. Bits 15–30 maybe used by application programs for user-defined permissions; they can be checked using theCCheckPerm instruction.

3.2.4 otype/eaddrThis 64-bit field holds the virtual address of the entry point of an executable capability. Thisfield also holds the “type” of a non-executable capability. The CSetType instruction sets theotype/eaddr field to the absolute virtual address of an entry point of an executable capability.The CSealCode instruction can then seal the executable capability and treat the entry point asa unique object type. Furthermore, the CSealData instruction may seal a non-executable ca-pability with the otype/eaddr of an unsealed executable capability. Possession of a capabilitywith the Permit Set Type permission authorizes a domain to call CSetType with a type withinthe capability’s range. This arrangement provides for the construction of matching executableand data-only capabilities of the same otype/eaddr to be used in protected procedure calls.

3.2.5 baseThis 64-bit field is the base virtual address of the segment described by a capability.

3.2.6 lengthThis 64-bit field is the length of the segment described by a capability.

3.2.7 Capability PermissionsTable 3.2 shows constants currently defined for memory permissions; remaining bits are software-defined.

Non Ephemeral Allow this capability to persist beyond a protected procedure return.

47

Value Name

0 Non Ephemeral1 Permit Execute2 Permit Load3 Permit Store4 Permit Load Capability5 Permit Store Capability6 Permit Store Ephemeral Capability7 Permit Seal8 Permit Set Type9 Reserved10 Access EPCC11 Access KDC12 Access KCC13 Access KR1C14 Access KR2C

Table 3.2: Memory permission bits for the perms capability field

Permit Execute Allow this capability to be used in the PCC register as a capability for theprogram counter.

Permit Store Capability Allow this capability to be used as a pointer for storing other capa-bilities.

Permit Load Capability Allow this capability to be used as a pointer for loading other capa-bilities.

Permit Store Allow this capability to be used as a pointer for storing data from general-purpose registers.

Permit Load Allow this capability to be used as a pointer for loading data into general-purpose registers.

Permit Store Ephemeral Capability Allow this capability to be used as a pointer for storingephemeral capabilities.

Permit Seal Allow this capability to be used to seal or unseal capabilities that have the sameotype/eaddr.

Permit Set Type Allow setting the otype/eaddr of this capability to any value between baseand base+length-1 if Permit Execute is also set.

Access EPCC Allow access to EPCC when this capability is in PCC.

Access KR1C Allow access to KR1C when this capability is in PCC.

Access KR2C Allow access to KR2C when this capability is in PCC.

48

07815

ExcCode RegNum

Figure 3.2: Capability Cause Register

Access KCC Allow access to KCC when this capability is in PCC.

Access KDC Allow access to KDC when this capability is in PCC.

Ephemeral capabilities can be stored only via capabilities that have the Permit Store Ephemeral Capabilitypermission bit set; normally, this permission will be set only on capabilities that, themselves,have the Non-Ephemeral bit cleared.

3.3 Capability ExceptionsMany of the capability instructions can cause an exception (e.g., if the program attempts a loador a store that is not permitted by the capability system). The ExcCode field within the causeregister of coprocessor 0 will be set to 18 (C2E, coprocessor 2 exception) when the cause ofthe exception is that the attempted operation is prohibited by the capability system. The currentPCC will be moved to EPCC and KCC will be moved into PCC, which should allow thekernel exception handler to run successfully.

Capability Cause Register

The capability coprocessor has a capcause register that gives additional information on thereason for the exception. It is formatted as shown in figure 3.2. The possible values for theExcCode of capcause are shown in table 3.3. If the last instruction to throw an exception didnot throw a capability exception, then the ExcCode field of capcause will be None. ExcCodevalues from 128 to 255 are reserved for use by application programs. (A program can useCSetCause to set ExcCode to a user-defined value).

The RegNum field of capcause will hold the number of the capability register whose per-mission was violated in the last exception, if this register was not the unnumbered registerPCC. If the capability exception was raised because PCC did not grant access to a numberedreserved register, then capcause will contain the number of the reserved register to which ac-cess was denied. If the exception was raised because PCC did not grant some other permission(e.g. permission to read capcause was required, but not granted) then RegNum will hold 0xff.

The CGetCause instruction can be used by an exception handler to read the capcauseregister. CGetCause will raise an exception if PCC.perms.Access EPCC is not set, so the op-erating system can prevent user space programs from reading capcause directly by not grantingthem Access EPCC permission.

Exception Priority

If an instruction throws more than one capability exception, capcause is set to the highestpriority exception (numerically lowest priority number) as shown in table 3.4. The RegNumfield of capcause is set to the register which caused the highest priority exception.

49

Value Description

0x00 None0x01 Length Violation0x02 Tag Violation0x03 Seal Violation0x04 Type Violation0x05 Call Trap0x06 Return Trap0x07 Underflow of trusted system stack0x08 User-defined Permission Violation0x10 Non Ephemeral Violation0x11 Permit Execute Violation0x12 Permit Load Violation0x13 Permit Store Violation0x14 Permit Load Capability Violation0x15 Permit Store Capability Violation0x16 Permit Store Ephemeral Capability Violation0x17 Permit Seal Violation0x18 Permit Set Type Violation0x19 reserved0x1a Access EPCC Violation0x1b Access KDC Violation0x1c Access KCC Violation0x1d Access KR1C Violation0x1e Access KR2C Violation0x1f reserved

Table 3.3: Capability Exception Codes

50

Priority Description

1 Access EPCC ViolationAccess KDC ViolationAccess KCC ViolationAccess KR1C ViolationAccess KR2C Violation

2 Tag Violation3 Seal Violation4 Type Violation5 Permit Seal Violation6 Permit Set Type Violation7 Permit Execute Violation8 Permit Load Violation

Permit Store Violation9 Permit Load Capability Violation

Permit Store Capability Violation10 Permit Store Ephemeral Capability Violation11 Non Ephemeral Violation12 Length Violation13 User-defined Permission Violation14 Call Trap

Return Trap

Table 3.4: Exception Priority

All capability exceptions (C2E) have higher priority than address error exceptions (AdEL,AdES).

If an instruction throws more than one capability exception with the same priority (e.g. boththe source and destination register are reserved registers), then the register which is furthest tothe left in the assembly language opcode has priority for setting the RegNum field.

Some of these priority rules are security critical. In particular, an exception caused by aregister being reserved must have priority over other capability exceptions (e.g., AdEL andAdES) to prevent a process from discovering information about the contents of a register thatit is not allowed to access.

Other priority rules are not security critical, but are defined by this specification so thatexception processing is deterministic.

Exceptions and indirect addressing

If an exception is caused by the combination of the values of a capability register and a generalpurpose register (e.g. if an expression such as clb t1, t0(c0) raises an exception becausethe offset t0 is trying to read beyond c0’s length), the number of the capability register (not ofthe general-purpose register) will be stored in capcause.RegNum.

51

Software Emulation of CCall and CReturn

In the current hardware implementation of CHERI, the CCall and CReturn instructions alwaysraise an exception, so that the details of the call or return operation can be implemented insoftware by a trap handler. This exception uses a different trap handler vector, at 0x100 abovethe general purpose exception handler. The exception cause will be C2E and capcause will beCall Trap for CCall and Return Trap for CReturn.

3.4 CPU ResetWhen the CPU is hard reset, all capability registers will be initialized to the following values:

• The tag bit is set.

• The u bit is set.

• base = 0

• length = 264 − 1

• otype/eaddr = 0

• All permissions bits are set.

• All unused bits are set.

The initial values of PCC and EPCC will allow the system to initially execute code relative tovirtual address 0. The initial value of C0 will allow general-purpose loads and stores to all ofvirtual memory for the bootstrapping process. The initial value of IDC will allow the creationof any further capabilities required to bootstrap the system.

3.5 Changes to Standard MIPS ProcessingThe following changes are made to the behavior of standard MIPS instructions when a capa-bility coprocessor is present:

Instruction fetch When the CPU fetches an instruction from PC, it indirects the instructionfetch through PCC. If the instruction fetch is not permitted due to a bounds check failure or apermission error (Permit Execute not set), coprocessor 2 exception (C2E) is thrown.

If an exception occurs during instruction fetch (e.g. AdEL, or a TLB miss) then BadVAddris set equal to PCC.base + PC.

Load and Store instructions When the CPU performs a standard MIPS load or store in-struction, the address to be read from (or written to) is indirected through C0. C0 must havethe appropriate permission (Permit Store or Permit Load) set, and the addresses read or writtenmust be between C0.base and C0.base + C0.length − 1. If the load or store is not permitteddue to a memory bound check failure or a permission error, a coprocessor 2 exception (C2E) isthrown.

52

031

S L 0

0 PFN C DVG

Table 3.5: EntryLo Register

Floating-point Load and Store instructions If the CPU is configured with a floating-pointunit, all loads and stores between the floating-point unit and memory are also relative toC0.base and checked against the permissions and bounds of C0.

Jump and link register After a jalr instruction, the return address is relative to PCC.base.

3.6 Changes to the TLB

CHERI adds two new fields to the EntryLo register, shown as L and S in Table 3.5. If L isset, capability loads are disabled for the page; if a load capability instruction is used on a pagewith the L bit set, then an exception will be raised, setting CP0.Cause.ExcCode to 16. Thisexception will be raised even if the corresponding tag bit was not set (i.e., the bytes to beloaded were non-capability data). If S is set, capability stores are disabled for the page; if astore capability instruction is used on a page with the S bit set, then an exception will be raised,setting CP0.Cause.ExcCode to 17. This exception will be raised even if the tag bit was unset inthe capability register to be stored (i.e., it contained non-capability data).

3.7 Proposed Extensions to the CHERI ISA

The following changes have been discussed and are targeted for short-term implementation inthe CHERI ISA:

• Move MIPS memory-access interposition from C0 to a control register accessed via spe-cial instructions, as is the case for PCC.

• Define a NULL capability, which could be loaded from C0, to make checks easy to imple-ment. A capability NULL would have the tag bit set (valid capability), but grant no accessrights (cannot be dereferenced, and can be safely delegated – unlike C NULL which, whencast to a capability, grants full address-space rights).

• Provide some means of efficiently implementing a capability tag-clearing memcpy()

that will not throw a fault when a capability is found in source memory. This might bea new load instruction variant that clears tags, or could be a variant on CClearTag thatpreserves (useful) data while clearing the tag. With an explicit zero-capability register,CClearTag could just clear the tag, not the data; however, an exception would still resultif the source did not have load-capability permissions.

53

• Allow CCall/CReturn instructions to partially implement capability call/return seman-tics while still throwing an exception to allow software processing. For example, theymight implement all necessary checks so that software does not need to do this.

• Implement an explicit capability cursor, completing support for fat-pointer style opera-tion. A capability cursor will differentiate the point of access for a load or store operationfrom the bounds imposed on that access; the cursor would move flexibly but loads andstores would trigger an exception if they occur while the cursor points outside of thepermitted bounds. This might be of particular use in supporting C pointer arithmetic, inwhich some application programs temporarily construct pointers that are invalid – e.g.,during packet parsing – that they will not dereference. Early prototyping of such anapproach, reusing the entry address/type field as a cursor, suggests that it might proveeffective in improving C compatibility for complex buffer management code.

The following changes have been discussed for longer-term consideration in the CHERIISA:

• Allow CReturn to accept code/data capability arguments, which might be ignored forthe time being.

• 32-byte capabilities impose measurable overhead; implementing a 16-byte “compressedcapability” representation, usable for pure data capabilities, might reduce this overhead.In order for this to be useful, the compiler must be able to statically determine and con-trol use of compressed capabilities. Initial simulations of 128-bit capabilities suggest asubstantial reduction in cache footprint.

54

Chapter 4

Instruction-Set Reference

CHERI instructions fall into a number of categories: instructions to copy fields from capabil-ity registers into general-purpose registers so that they can be computed on, instructions forrefining fields within capabilities, instructions for memory access via capabilities, instructionsfor jumps via capabilities, instructions for sealing capabilities, and instructions for capabilityinvocation. Table 4.1 lists available capability coprocesor instructions.

4.1 Details of Individual InstructionsThe following sections provide a detailed description of each CHERI ISA instructions. Eachinstruction description includes the following information:

• Instruction opcode format number

• Assembly language syntax

• Bitwise figure of the instruction layout

• Text description of the instruction

• Pseudo-code description of the instruction

• Enumeration of any exceptions that the instruction can trigger

55

Mnemonic Description

CGetBase Move base to a general-purpose registerCGetLen Move length to a general-purpose registerCGetTag Move tag bit to a general-purpose registerCGetUnsealed Move unsealed bit to a general-purpose registerCGetPerm Move permissions field to a general-purpose registerCGetType Move object type field to a general-purpose register

CGetPCC Move the PCC and PC to general-purpose registersCGetCause Move capability exception cause register to a general-purpose registerCSetCause Set the capability exception cause register

CIncBase Increase BaseCMove Pseudo-instruction for CIncBase with no change to the baseCSetLen Set LengthCClearTag Clear the tag bitCAndPerm Restrict PermissionsCSetType Set the otype/eaddr of an executable capability

CCheckPerm Check perms fieldCCheckType Check otype/eaddr field

CFromPtr Create capability from pointerCToPtr Capability to pointer

CBTU Branch if capability tag is unsetCBTS Branch if capability tag is set

CSC Store Capability RegisterCLC Load Capability RegisterCL[BHWD][U] Load Byte, Half-Word, Word or Double Via Capability Register (Unsigned)CS[BHWD] Store Byte, Half-Word, Word or Double Via Capability Register

CLLD Load linked doubleword via capability registerCSCD Store conditional doubleword via capability pregister

CJR Jump Capability RegisterCJALR Jump and link Capability Register

CSealCode Seal an executable capabilityCSealData Seal a non-executable capability with the otype/eaddr of an executable

capabilityCUnseal Unseal a sealed capability

CCall Protected procedure call into a new security domainCReturn Return to the previous security domain

Figure 4.1: Capability coprocessor instruction summary

56

CGetBase: Move Base to a General-Purpose RegisterFormat (4)

CGetBase rd, cb023101115162021252631

0x12 0x00 rd cb 0x2

Description

General-purpose register rd is set equal to the base field of capability register cb.

Pseudocode

if register inaccessible(cb) thenraise c2 exception()

elserd← cb.base

end if

Exceptions

A coprocessor 2 exception is raised if:

• cb is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) and the corre-sponding bit in PCC.perms is not set.

57

CGetLen: Move Length to a General-Purpose RegisterFormat (4)

CGetLen rd, cb023101115162021252631

0x12 0x00 rd cb 0x3

Description

General-purpose register rd is set equal to the length field of capability register cb.

Pseudocode


elserd← cb.length

end if

Exceptions



58

CGetTag: Move Tag to a General-Purpose RegisterFormat (4)

CGetTag rd, cb023101115162021252631

0x12 0x00 rd cb 0x5

Description

The low bit of rd is set to the tag value of cb. All other bits are cleared.

Pseudocode


elserd[0]← cb.tagrd[1:63]← 0

end if

Exceptions



59

CGetUnsealed: Move sealed bit to a General-Purpose RegisterFormat (4)

CGetUnsealed rd, cb023101115162021252631

0x12 0x00 rd cb 0x6

Description

The low-order bit of rd is set to cb.u. All other bits of rd are cleared.

Pseudocode


elserd[0]← cb.unsealedrd[1:63]← 0

end if

Exceptions



60

CGetPerm: Move Memory Permissions Field to a General-Purpose Regis-terFormat (4)

CGetPerm rd, cb023101115162021252631

0x12 0x00 rd cb 0x0

Description

The least significant 15 bits (bits 0 to 14) of general-purpose register rd are set equal to theperms field of capability register cb. The other bits of rd are set to zero.

Pseudocode


elserd[0:14]← cb.permsrd[15:63]← 0

end if

Exceptions



61

CGetType: Move Object Type Field to a General-Purpose RegisterFormat (4)

CGetType rd, cb023101115162021252631

0x12 0x00 rd cb 0x1

Description

General-purpose register rd is set equal to the otype/eaddr field of capability register cb.

Pseudocode


elserd← cb.otype

end if

Exceptions



62

CGetPCC: Move the PCC and PC to General-Purpose RegistersFormat (4)

CGetPCC rd(cd)023101115162021252631

0x12 0x00 rd cd 0x7

Description

General-purpose register rd is set equal to the PC and the capability register cd is set to thePCC.

Pseudocode

if register inaccessible(cd) thenraise c2 exception()

elserd← PCcd← PCC

end if

Exceptions


• cd is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) and the cor-responding bit in PCC.perms is not set.

63

CGetCause: Move the Capability Exception Cause Register to a General-Purpose RegisterFormat (4)

CGetCause rd023101115162021252631

0x12 0x00 rd 0x00 0x4

Description

General-purpose register rd is set equal to the capability cause register.

Pseudocode

if not PCC.perms.Access EPCC thenraise c2 exception(exceptionAccessEPCC, 0xff)

elserd← CapCause

end if

Exceptions


• PCC.perms.Access EPCC is not set.

64

CSetCause: Set the Capability Exception Cause RegisterFormat (1)

CSetCause rt02356101115162021252631

0x12 0x04 0x00 0x00 rt 0x4

Description

The capability cause register value is set to the low 16 bits of general-purpose register rt.

Pseudocode

if not PCC.perms.Access EPCC thenraise c2 exception(exceptionAccessEPCC, 0xff)

elseCapCause← rt

end if

Exceptions


• PCC.perms.Access EPCC is not set.

65

CIncBase: Increase Base

Format (1)

CIncBase cd, cb, rtCMove cd, cb

02356101115162021252631

0x12 0x04 cd cb rt 0x2

Description

Capability register cd is replaced with the contents of capability register cb with the base fieldset to the sum of its previous value and the contents of general-purpose register rt. The lengthfield of capability register cd is replaced with cb.length minus the contents of general-purposeregister rt, ensuring that capability register cd points to a subset of the original memory region.

Pseudocode


else if register inaccessible(cb) thenraise c2 exception()

else if not cb.tag and rt 6= 0 thenraise c2 exception(exceptionTag, cb)

else if not cb.unsealed and rt 6= 0 thenraise c2 exception(exceptionSealed, cb)

else if rt > cb.length thenraise c2 exception(exceptionLength, cb)

elsecd← cbcd.base← cb.base + rtcd.length← cb.length − rt

end if

Exceptions


• cb or cd is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) and thecorresponding bit in PCC.perms is not set.

• cb.tag is not set and rt 6= 0.

• cb.u is not set and rt 6= 0.

• rt > cb.length

66

Notes

• CIncBase can be used to copy one register to another by setting rt equal to zero. If rtis zero, the operation will succeed even if cb.u is not set, allowing it to be used to copysealed capabilities. CIncBase also succeeds if rt is zero and cb.tag is unset, allowing itto be used to copy non-capability data items between capability registers.

• In assembly language, CMove cd, cb is a pseudo-instruction which the assembler con-verts to CIncBase cd, cb, $zero.

67

CSetLen: Set LengthFormat (1)

CSetLen cd, cb, rt02356101115162021252631


Description

Capability register cd is replaced with the contents of capability register cb with the lengthfield set to the contents of general-purpose register rt.

Pseudocode



else if not cb.tag thenraise c2 exception(exceptionTag, cb)

else if not cb.unsealed thenraise c2 exception(exceptionSealed, cb)


elsecd← cbcd.length← rt

end if

Exceptions


• cb.tag is not set.()


• cb.u is not set.

• rt > cb.length

Notes

Unlike CIncBase, this operation will always raise an exception if cb.tag or cb.u are unset, evenif the length is unchanged.

68

CClearTag: Clear the tag bitFormat (1)

CClearTag cd, cb

023101115162021252631

0x12 0x04 cd cb 0x5

Description

Capability register cd is replaced with the contents of cb, with the tag bit cleared.

Pseudocode


else if register inaccessible(cd) thenraise c2 exception()

elsecd← cbcd.tag← false

end if

Exceptions



69

CAndPerm: Restrict PermissionsFormat (1)

CAndPerm cd, cb, rt02356101115162021252631


Description

Capability register cd is replaced with the contents of capability register cb with the permsfield set to the bitwise AND of its previous value and the contents of general-purpose registerrt.

Pseudocode





elsecd← cbcd.perms← cb.perms ∩ rt

end if

Exceptions



• cb.tag is not set.


70

CSetType: Set the otype of a CapabilityFormat (1)

CSetType cd, cb, rt02356101115162021252631


Description

Capability register cd is replaced with the contents of cb, with the otype/eaddr field set tocb.base+rt and the Permit Seal bit in the perms field set.

Purpose

CSetType is used to set the otype/eaddr field of a capability. otype/eaddr has two relatedpurposes:

1. If the capability is subsequently sealed with CSealCode and called with CCall, thencontrol will be transferred to the address given by its otype/eaddr. In terms of objectoriented programming, the otype/eaddr is the address of some code that implements themethods of a class.

2. If the capability is subsequently used as the ct parameter to CSealData or CUnseal,otype/eaddr acts as a unique identifier for a user-defined class: only subsystems thathave a capability for that otype/eaddr value are permitted to seal or unseal capabilitieswith that otype/eaddr. In terms of object oriented programming, otype/eaddr grantspermission to create or examine the internal structure of objects of a particular class.

The connection between the two is that it is the methods of the class (purpose 1) that aregranted permission to create or examine the internal structure of members of the class (purpose2). The same field is used for both purposes to save bits within a capability, and because theentry point of the methods serves as a convenient unique identifier for the class.

Pseudocode





else if not cb.perms.Permit Set Type thenraise c2 exception(exceptionPermitSetType, cb)

else if rt ≥ cb.length thenraise c2 exception(exceptionLength, cb)

71

elsecd← cbcd.otype← cb.base + rtcd.perms.Permit Seal← true

end if

Exceptions




• cb.perms.Permit Set Type is not set.

• rt ≥ cb.length.

72

CCheckPerm: Raise exception if don’t have permissionFormat

CCheckPerm cs, rt02356101115162021252631

0x12 0x0b cs rt 0x0

Description

A exception is raised (and the capability cause set to “user defined permission violation”) ifthere is a bit set in rt which is not set in cs.perms (i.e. rt describes a set of permissions, and anexception is raised if cs does not grant all of those permissions).

Pseudocode

if register inaccessible(cs) thenraise c2 exception()

else if not cs.tag thenraise c2 exception(exceptionTag, cs)

else if cs.perms ∩ rt 6= rt thenraise c2 exception(exceptionUserDefined, cs)

end if

Exceptions


• cs is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) and the corre-sponding bit in PCC.perms is not set.

• cs.tag is not set.

• There is a bit which is set in rt and is not set in cs.perms.

Notes

• If cs.tag is not set, then cs does not contain a capability, cs.perms might not be meaning-ful as a permissions field, and so a tagViolation exception is raised.

• This instruction can be used to check the permissions field of a sealed capability, so theinstruction does not check cs.u.

73

CCheckType: Raise exception if otypes don’t matchFormat (3)

CCheckType cs, cb02356101115162021252631

0x12 0x0b cs cb 0x1

Description

An exception is raised if cs.otype/eaddr is not equal to cb.otype/eaddr.

Pseudocode



else if not cs.tag thenraise c2 exception(exceptionTag)

else if not cb.tag thenraise c2 exception(exceptionTag)

else if cs.unsealed thenraise c2 exception(exceptionSealed)

else if cb.unsealed thenraise c2 exception(exceptionSealed)

else if cs.otype 6= cb.otype thenraise c2 exception(exceptionType)

end if

Exceptions


• cs or cb is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) and thecorresponding bit in PCC.perms is not set.



• cs.u is set.

• cs.u is set.

• cs.otype/eaddr6= cb.otype/eaddr.

74

CFromPtr: Create capability from pointerFormat (1)

CFromPtr cd, cb, rt02356101115162021252631


Description

rt is a pointer using the C-language convention that a zero value represents the NULL pointer.If rt is zero, then cd will be the NULL capability (tag bit set, all other bits unset). If rt isnon-zero, then cd will be a capability whose base is cb.base+rt.

Pseudocode



else if rt = 0 thencd.tag = truecd.base = 0cd.length = 0cd.perms = ∅cd.reserved = 0




elsecd← cbcd.base← cb.base + rtcd.length← cb.length − rt

end if

Exceptions





75

• rt > cb.length.

76

CToPtr: Capability to PointerFormat

CToPtr rd, cb, ct056101115162021252631

0x12 0x0c rd cb ct

Description

If cb has its tag bit set but is of zero length (i.e. it is either the NULL capability, or some othercapability of zero length), then rd is set to zero.

If the memory addresses cb.base . . . cb.base + cb.length − 1 are contained within ct.base. . . ct.base + ct.length − 1, then rd is set to the offset cb.base − ct.base.

This instruction can be used to convert a capability into a pointer that uses the C languageconvention that a zero value represents the NULL pointer. Note that rd will also be zero ifcb and ct have the same base; this is similar to the C language not being able to distinguish aNULL pointer from a pointer to a structure at address 0.

Pseudocode


else if register inaccessible(ct) thenraise c2 exception()


else if not ct.tag thenraise c2 exception(exceptionTag, ct)

else if cb.length = 0 thenrd← 0

else if cb.base < ct.base thenraise c2 exception(exceptionLength, ct)

else if cb.base + cb.length > ct.base + ct.length thenraise c2 exception(exceptionLength, ct)

elserd← cb.base − ct.base

end if

Exceptions

A coprocessor 2 exception will be raised if:

• cb or ct is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) and thecorresponding bit in PCC.perms is not set.


77

• ct.tag is not set.

• cb.length 6= 0 and cb.base < ct.base

• cb.length 6= 0 and cb.base + cb.length > ct.base + ct.length

Notes

• cb or ct being sealed will not cause an exception to be raised. This is for further study.

78

CBTU: Branch if tag is unsetFormat (6?)

CBTU cb, offset015162021252631

0x12 0x09 cb offset

Description

Sets the PC to PC+offset, where offset is sign extended, if cb.tag is not set.The instruction following the branch, in the delay slot, is executed before branching.

Pseudocode


else if not cb.tag thenif PC + offset + 4 > PCC.length then

raise c2 exception(exceptionLength, 0xff)else

execute delay slot()PC← PC + offset

end ifend if

Exceptions



• PC+offset+4 is greater than PCC.length and cb.tag is not set.

Notes

1. Like all MIPS branch instructions, CBTU has a branch delay slot. The instruction afterit will always be executed, regardless of whether the branch is taken or not.

79

CBTS: Branch if tag is setFormat (6?)

CBTS cb, offset015162021252631

0x12 0x0a cb offset

Description

Sets the PC to PC+offset, where offset is sign extended, if cb.tag is set.The instruction following the branch, in the delay slot, is executed before branching.

Pseudocode


else if cb.tag thenif PC + offset + 4 > PCC.length then

raise c2 exception(exceptionLength, 0xff)else

execute delay slot()PC← PC + offset

end ifend if

Exceptions



• RPC+offset+4 is greater than PCC.length and cb.tag is set.

Notes

1. Like all MIPS branch instructions, CBTS has a branch delay slot. The instruction after itwill always be executed, regardless of whether the branch is taken or not.

80

CSC: Store Capability RegisterFormat (3)

CSC cs, rt, offset(cb)CSCR cs, rt(cb)CSCI cs, offset(cb)

056101115162021252631

0x3e cs cb rt offset

Description

Capability register cs is stored at the memory location specified by cb.base + general-purposeregister rt, and the bit in the tag memory associated with cb.base + rt is set. Capability registercb must contain a capability that grants permission to store capabilities. The virtual addresscb.base + rt must be 32-byte word aligned.

The capability is stored in memory in the format described in Figure 3.1. base, length andotype/eaddr are stored in memory with the same endian-ness that the CPU uses for double-word stores, i.e., big-endian. The bits of perms are stored with bit zero being the least signifi-cant bit, so that the least significant bit of the eighth byte stored is the u bit, the next significantbit is the Non Ephemeral bit, the next is Permit Execute and so on.

Pseudocode





else if not cb.perms.Permit Store Capability thenraise c2 exception(exceptionPermitStoreCapability, cb)

else if not cb.perms.Permit Store Ephemeral Capability and not cs.perms.Non Ephemeralthen

raise c2 exception(exceptionPermitStoreEphemeralCapability, cb)end ifaddr← cb.base + rt + offsetif rt + offset + 32 > cb.length then

raise c2 exception(exceptionLength, cb)else if rt + offset < 0 then

raise c2 exception(exceptionLength, cb)else if align of(addr) < 32 then

raise exception(exceptionAdES)else

mem[addr]← cs

81

tags[toTag(addr)]← cs.tagend if

Exceptions




• The virtual address rt + offset + 32 is greater than cb.length.

• cb.perms.Permit Store Capability is not set.


• cb.perms.Permit Store Ephemeral is not set and cs.perms.Non Ephemeral is not set.

An address error during store (AdES) exception is raised if:

• The virtual address cb.base + rt + offset is not 32-byte word aligned.

Notes

• If the address alignment check fails and one of the security checks fails, a coprocessor 2exception (and not an address error exception) is raised. The priority of the exceptionsis security-critical, because otherwise a malicious program could use the type of theexception that is raised to test the bottom bits of a register that it is not permitted toaccess.

• offset is interpreted as a signed integer.

• This instruction reuses the opcode from the Store Doubleword from Coprocessor 2 (SDC2)instruction in the MIPS Specification.

• The CSCI mnemonic is equivalent to CSC with cb being the zero register ($zero). TheCSCR mnemonic is equivalent to CSC with offset set to zero.

82

CLC: Load Capability Register

Format (1)

CLC cd, rt, offset(cb)CLCR cd, rt(cb)CLCI cd, offset(cb)

056101115162021252631

0x36 cd cb rt offset

Description

Capability register cd is loaded from the memory location specified by cb.base + general-purpose register rt. Capability register cb must contain a capability that grants permission toload capabilities. The virtual address cb.base + rt must be 32-byte word aligned.

The bit in the tag memory corresponding to cb.base + rt is loaded into the tag bit associatedwith cd.

Pseudocode





else if not cb.perms.Permit Load Capability thenraise c2 exception(exceptionPermitLoadCapability, cb)

end ifaddr← cb.base + rt + offsetif rt + offset + 32 > cb.length then



raise exception(exceptionAdEL)else

cd← mem[addr]cd.tag← tags[toTag(addr)]

end if

Exceptions


83



• cb.perms.Permit Load Capability is not set.


• rt + offset + 32 is greater than cb.length.

• rt + offset < 0.

An address error during load (AdEL) exception is raised if:

1. The virtual address cb.base + rt is not 32-byte word aligned.

Notes

• This instruction reuses the opcode from the Load Doubleword to Coprocessor 2 (LDC2)instruction in the MIPS Specification.

• offset is interpreted as a signed integer.

• The CLCI mnemonic is equivalent to CLC with cb being the zero register ($zero). TheCLCR mnemonic is equivalent to CLC with offset set to zero.

84

Load Via Capability RegisterFormat

CLB rd, rt, offset(cb)CLH rd, rt, offset(cb)CLW rd, rt, offset(cb)CLD rd, rt, offset(cb)CLBU rd, rt, offset(cb)CLHU rd, rt, offset(cb)CLWU rd, rt, offset(cb)CLBR rd, rt(cb)CLHR rd, rt(cb)CLWR rd, rt(cb)CLDR rd, rt(cb)CLBUR rd, rt(cb)CLHUR rd, rt(cb)CLWUR rd, rt(cb)CLBI rd, offset(cb)CLHI rd, offset(cb)CLWI rd, offset(cb)CLDI rd, offset(cb)CLBUI rd, offset(cb)CLHUI rd, offset(cb)CLWUI rd, offset(cb)

013101115162021252631

0x32 rd cb rt offset s t

Purpose

Loads a data value via a capability register, and extends the value to fit the target register.

Description

The lower part of general-purpose register rd is loaded from the memory location specifiedby cb.base + rt + offset. Capability register cb must contain a valid capability that grantspermission to load data.

The size of the value loaded depends on the value of the t field:

0 byte (8 bits)

1 halfword (16 bits)

2 word (32 bits)

3 doubleword (64 bits)

The extension behavior depends on the value of the s field: 1 indicates sign extend, 0indicates zero extend. For example, CLWU is encoded by setting s to 0 and t to 2, CLB isencoded by setting both to 0.

85

Pseudocode




else if not cb.perms.Permit Load thenraise c2 exception(exceptionPermitLoad, cb)

end ifif t = 0 then

size← 1else if t = 1 then



size← 8end ifaddr← cb.base + rt + offsetif offset + rt + size > cb.length then

raise c2 exception(exceptionLength, cb)else if offset + rt < 0 then

raise c2 exception(exceptionLength, cb)else if align of(addr) < size then

raise exception(exceptionAdEL)else if s = 0 then

rd← zero extend(mem[addr:addr + size − 1])else

rd← sign extend(mem[addr:addr + size − 1])end if

Exceptions




• Immediate offset + rt + size is greater than cb.length. Check depends on the size of thedata loaded.

• cb.perms.Permit Load is not set.


86

Notes

• This instruction reuses the opcode from the Load Word to Coprocessor 2 (LWC2) in-struction in the MIPS Specification.

• rt and offset are treated as signed integers.

• The result of the addition does not wrap around (i.e., an exception is raised if cb.base+rt+offsetis less than zero, or greater than maxaddr).

87

Store Via Capability RegisterFormat

CSB rs, rt, offset(cb)CSH rs, rt, offset(cb)CSW rs, rt, offset(cb)CSD rs, rt, offset(cb)CSBR rs, rt(cb)CSHR rs, rt(cb)CSWR rs, rt(cb)CSDR rs, rt(cb)CSBI rs, offset(cb)CSHI rs, offset(cb)CSWI rs, offset(cb)CSDI rs, offset(cb)

013101115162021252631

0x3A rs cb rt offset 0 t

Purpose

Stores some or all of a register into a memory location.

Description

Part of general-purpose register rs is stored to the memory location specified by cb.base + rt +offset. Capability register cb must contain a capability that grants permission to store data.

The t field determines how many bits of the register are stored to memory:

0 byte (8 bits)

1 halfword (16 bits)

2 word (32 bits)

3 doubleword (64 bits)

If less than 64 bits are stored, they are taken from the least-significant end of the register.

Pseudocode




88

else if not cb.Permit Store thenraise c2 exception(exceptionPermitStore, cb)

end ifif t = 0 then




size← 8end ifaddr← cb.base + rt + offsetif rt + offset + size > cb.length then


raise c2 exception(exceptionLength, cb)else if align of(addr) < size then

raise exception(exceptionAdES)else

mem[addr:addr + size − 1]← rd[0:size − 1]tags[toTag(addr)]← false

end if

Exceptions




• Immediate offset + size is greater than cb.length.

• cb.perms.Permit Store is not set.


Notes

• This instruction reuses the opcode from the Store Word from Coprocessor 2 (SWC2)instruction in the MIPS Specification.

• If t is 3 and e is 1, then the instruction is CSCD (Store Conditional Doubleword viaCapability).

• rt and offset are treated as signed integers.

89

• The result of the addition does not wrap around (i.e., an exception is raised if cb.base+rt+offsetis less than zero, or greater than maxaddr).

90

CLLD: Load Linked Doubleword via CapabilityFormat

CLLD rd, rt, offset(cb)CLLDR rd, rt(cb)CLLDI rd, offset(cb)

023101115162021252631

0x32 rd cb rt offset 111

Description

CLLD and CSCD are used to implement safe access to data shared between different threads.The typical usage is that CLLD is followed (an arbitrary number of instructions later) by CSCDto the same address; the CSCD will only succeed if there have been no context switches sincethe preceding CLLD.

The exact conditions under which CSCD fails are implementation dependent, particularlyin multicore or multiprocessor implementations). The following pseudocode is intended to rep-resent the security semantics of the instruction correctly, but should not be taken as a definitionof the CPU’s memory coherence model.

Pseudocode

addr← cb.base + rt + offsetif register inaccessible(cb) then

raise c2 exception()else if not cb.tag then

raise c2 exception(exceptionTag, cb)else if not cb.unsealed then

raise c2 exception(exceptionSealed, cb)else if not cb.perms.Permit Load then

raise c2 exception(exceptionPermitLoad, cb)else if offset + rt + 8 > cb.length then

raise c2 exception(exceptionLength, cb)else if offset + rt < 0 then


raise c2 exception(exceptionAdEL)else

rd← mem[addr:addr+7]linkedFlag← true

end if

91

CSCD: Store Conditional Doubleword via CapabilityFormat

CSCD rs, rt, offset(cb)CSCDR rs, rt(cb)CSCRI rs, offset(cb)

023101115162021252631

0x3A rs cb rt offset 111

Pseudocode

addr← cb.base + rt + offsetif register inaccessible(cb) then

raise c2 exception()else if not cb.tag then

raise c2 exception(exceptionTag, cb)else if not cb.unsealed then

raise c2 exception(exceptionSealed, cb)else if not cb.perms.Permit Store then

raise c2 exception(exceptionPermitStore, cb)else if rt + offset + 32 > cb.length then



raise exception(AdES)else if not linkedFlag then

rs← 0else

mem[addr:addr+7]← rstags[toTag(addr)]← falsers← 1

end if

92

CJR: Jump Capability RegisterFormat (3)

CJR rt(cb)056101115162021252631

0x12 0x08 cb rt

Description

PCC is loaded from cb, and PC is loaded from rt. (As the program counter is relative to PCC,this instruction will branch to the address cb.base + rt).

Pseudocode




else if not cb.perms.Permit Execute thenraise c2 exception(exceptionPermitExecute, cb)

else if not cb.perms.Non Ephemeral thenraise c2 exception(exceptionNonEphemeral, cb)

end ifif rt + 4 > cb.length then

raise c2 exception(exceptionLength, cb)else if align of(cb.base + rt) < 4 then


execute delay slot()PC← rtPCC← cb

end if

Exceptions





• cb.perms.Permit Execute is not set.

93

• cb.perms.Non Ephemeral is not set.

• Register rt + 4 is greater than cb.length.

An address error exception is raised if:

• cb.base + rt is not 4-byte word aligned.

cb.base, cb.length and rt are treated as unsigned integers, and the result of the addition doesnot wrap around (i.e., an exception is raised if cb.base+rt is greater than maxaddr).

94

CJALR: Jump and Link Capability RegisterFormat (3)

CJALR rt(cb)056101115162021252631

0x12 0x07 cb rt

Description

The current PCC is saved in the return capability register (capability register number 24) andPC is saved in general purpose register ra (register number 31). PCC is then loaded fromcapability register cb, and PC is loaded from rt. As PC is interpreted relative to PCC duringinstruction fetch, this instruction will jump to the code at address cb.base+ rt.

Pseudocode




else if not cb.perms.Permit Execute thenraise c2 exception(exceptionPermitExecute, cb)

else if not cb.perms.Non Ephemeral thenraise c2 exception()

end ifif rt + 4 > cb.length then

raise c2 exception(exceptionLength, cb)else if align of(cb.base + rt) < 4 then


execute delay slot()R31← PCRCC← PCCPC← rtPCC← cb

end if

Exceptions

A coprocessor 2 exception will be raised if:


• cb.perms.Permit Execute is not set.

95

• rt + 4 is greater than cb.length.



• cb.perms.Non Ephemeral is not set.

An address error exception will be raised if

• cb.base + rt is not 4-byte word aligned.

96

CSealCode: Seal an Executable CapabilityFormat (5)

CSealCode cd, cs0101115162021252631

0x12 0x01 cd cs

Description

If

• capability register cs is unsealed;

• cs.perms.Permit Seal is set;

• and cs.perms.Permit Execute is set;

then

• cd.u is cleared.

• the other fields of cd (including otype/eaddr) are copied from cs.

Pseudocode


else if register inaccessible(cs) thenraise c2 exception()


else if not cs.unsealed thenraise c2 exception(exceptionSealed, cs)

else if not cs.perms.Permit Seal thenraise c2 exception(exceptionPermitSeal, cs)

else if not cs.perms.Permit Execute thenraise c2 exception(exceptionPermitExecute, cs)

elsecd← cscd.u← false

end if

Exceptions


• cd or cs is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) and thecorresponding bit in PCC.perms is not set.

97


• cs.u is not set.

• cs.perms.Permit Seal is not set.

• cs.perms.Permit Execute is not set.

98

CSealData: Seal a Data CapabilityFormat (5)

CSealData cd, cs, ct056101115162021252631

0x12 0x02 cd cs ct

Description

If

• capability register ct contains an unsealed capability;

• ct.perms.Permit Seal is set;

• capability register cs contains an unsealed capability;

• and cs.perms.Permit Execute is not set

then

• cd.otype/eaddr is set to ct.otype/eaddr;

• cd.u is cleared;

• and the other fields of cd are copied from cs.

Pseudocode






else if not ct.unsealed thenraise c2 exception(exceptionSealed, ct)

else if not cs.unsealed thenraise c2 exception(exceptionSealed, cs)

else if not ct.perms.Permit Seal thenraise c2 exception(exceptionPermitSeal, ct)

else if cs.perms.Permit Execute thenraise c2 exception(exceptionPermitExecute, cs)

else

99

cd← cscd.u← falsecd.otype← ct.otype

end if

Exceptions


• cd, cs, or ct is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) andthe corresponding bit in PCC.perms is not set.


• ct.u is not set.

• ct.perms.Permit Seal is not set.


• cs.u is not set.

• cs.perms.Permit Execute is set.

100

CUnseal: Unseal a sealed capabilityFormat (5)

CUnseal cd, cs, ct056101115162021252631

0x12 0x03 cd cs ct

Description

The sealed capability in cs is unsealed with ct and the result placed in cd. The not-ephemeralbit of cd is the AND of the ephemeral bits of cs and ct. ct must be unsealed, have Permit Sealpermission, and have the same otype/eaddr as cs.

Pseudocode






else if cs.unsealed thenraise c2 exception(exceptionSealed, cs)

else if not ct.unsealed thenraise c2 exception(exceptionSealed, ct)

else if ct.otype 6= cs.otype thenraise c2 exception(exceptionType, ct)

else if not ct.perms.Permit Seal thenraise c2 exception(exceptionPermitSeal, ct)

elsecd← cscd.u← truecd.perms.Non Ephemeral← cs.perms.Non Ephemeral and ct.perms.Non Ephemeral

end if

Exceptions


• cd, cs, or ct is one of the reserved registers (KR1C, KR2C, KCC, KDC or EPCC) andthe corresponding bit in PCC.perms is not set.


101

• ct.u is not set.

• ct.perms.Permit Seal is not set.

• ct.otype/eaddr 6= cs.otype/eaddr.


• cs.u is set.

102

CCall: Call into a new security domainFormat (3)

CCall cs, cb0101115162021252631

0x12 0x05 cs cb

Description

CCall is used to make a call into a protected subsystem (which may have access to a differentset of capabilities than its caller). cs contains a code capability for the subsystem to be called,and cb contains a sealed data capability which will be unsealed for use by the called subsystem.In terms of object-oriented programming, cb is a capability for an object and cs is a capabilityfor the methods of the object’s class.

In the current implementation of CHERI, CCall is implemented by the hardware that raisesan exception, and the rest of the instruction’s behavior is to be implemented in software by thetrap handler.

Later versions of CHERI may implement more of this instruction in hardware, for improvedperformance.

Authors of compilers or assembly language programs should not rely on CCall being im-plemented in software.

1. The program counter (PC) + 4, the stack pointer (SP), and 16 bytes of padding arepushed onto the trusted system stack. (The padding exists to keep the trusted systemstack aligned on a 32-byte boundary).

2. PCC is pushed onto the trusted system stack.

3. IDC is pushed onto the trusted system stack.

4. cs is unsealed and the result placed in PCC.

5. cb is unsealed and the result placed in IDC.

6. The program counter is set to cs.otype/eaddr− cs.base. (i.e. control branches to virtualaddress cs.otype/eaddr, but because the program counter is relative to PCC.base, thismust be subtracted).

Pseudocode (hardware)

raise c2 exception(exceptionCall, cs)

Pseudocode (software)



103



else if cs.unsealed thenraise c2 exception(exceptionSealed, cs)

else if cb.unsealed thenraise c2 exception(exceptionSealed, cb)

else if cs.otype 6= cb.otype thenraise c2 exception(exceptionType, cs)

else if not cs.perms.Permit Seal thenraise c2 exception(exceptionPermitSeal, cs)

else if not cs.perms.Permit Execute thenraise c2 exception(exceptionPermitExecute, cs)

else if cs.otype < cs.base thenraise c2 exception(exceptionLength, cs)

else if cs.otype > cs.base + cs.length − 1 thenraise c2 exception(exceptionLength, cs)

elseTSS← TSS − 32mem[TSS .. TSS + 7]← PC + 4mem[TSS + 8 .. TSS + 15]← SPtags[toTag(TSS)]← falseTSS← TSS − 32mem[TSS .. TSS + 31]← PCCtags[toTag(TSS)]← PCC.tagTSS← TSS − 32mem[TSS .. TSS + 31]← IDCtags[toTag(TSS)]← TSS.tagPCC← csPCC.unsealed← trueIDC← cbIDC.unsealed← truePC← cs.otype − cs.base

end if

Exceptions

A coprocessor 2 exception will be raised so that the desired semantics can be implemented in atrap handler.

The capability exception code will be 0x05 and the handler vector will be 0x100 above thegeneral purpose exception handler.

A further coprocessor 2 exception raised if:


104

• cs.u is set.

• cb.u is set.

• cs.otype/eaddr 6= cb.otype/eaddr

• cs.perms.Permit Execute is not set.

• cs.perms.Permit Seal is not set.

• cs.otype/eaddr < cs.base

• cs.otype/eaddr > cs.base + cs.length - 1

• The trusted system stack would overflow (i.e., if PCC and IDC were pushed onto thesystem stack, it would overflow the bounds of TSC).

Notes

From the point of view of security, CCall needs to be an atomic operation (i.e. the caller cannotdecide to just do some of it, because partial execution could put the system into an insecurestate). From the point of view of hardware design, CCall needs to write two capabilities tomemory, which might take more than one clock cycle. One possible way to satisfy both ofthese constraints is to make CCall cause a software trap, and the trap handler uses its access toKCC and KDC to implement CCall.

105

CReturn: Return to the previous security domainFormat (3)

CReturn02021252631

0x12 0x06

Description

CReturn is used by a protected subsystem to return to its caller.

1. IDC is popped off the trusted system stack.

2. PCC is popped off the trusted system stack.

3. The program counter (PC) and stack pointer (SP) are popped off the trusted system stack.

In the current implementation of CHERI, CReturn is implemented by the hardware rais-ing an exception, while the rest of the behavior is implemented in software by the exceptionhandler. Later versions of CHERI may implement more of this instruction in hardware, forimproved performance. Authors of compilers or assembly language programs should not relyon CReturn being implemented in software.

Pseudocode (hardware)

raise c2 exception(exceptionReturn, 0xff)

Pseudocode (software)

IDC← mem[TSS .. TSS + 31]IDC.tag← tags[toTag(TSS)]TSS← TSS + 32PCC← mem[TSS .. TSS + 31]PCC.tag← tags[toTag(TSS)]TSS← TSS + 64PC← mem[TSS − 32 .. TSS − 25]SP← mem[TSS − 24 .. TSS − 17]

Exceptions

The exception raised when CReturn is implemented in software is a coprocessor 2 exception(C2E) with the capability cause code set to 0x6 (exceptionReturn) and RegNum set to cs. Thehandler vector for this exception is 0x100 above the general purpose exception handler.

An additional coprocessor 2 exception is raised if:

• The trusted system stack would underflow.

• The tag bits are not set on the memory location that are popped from the stack into IDCand PCC.

106

4.2 Assembler Pseudo-InstructionsFor convenience, several pseudo-instructions are accepted by the assembler. These expand toeither single instructions or short sequences of instructions.

4.2.1 Capability MoveCMove is a pseudo operation that moves a capability from one register to another. It expands toa CIncBase instruction, with $zero as the increment operand.

# The following are equivalent: CMove $c1, $c2 CIncBase $c1, $c2, $zero

4.2.2 Get/Set Default CapabilityCGetDefault and CSetDefault get and set the capability register that is used by the legacyMIPS load and store instructions. In the current version of the ISA, this register is C0. Thesepseudo-operations are provided for the benefit of the LLVM compiler: the compiler can moreeasily detect that a write to C0 affects the meaning of subsequent legacy MIPS instructions ifthese are separate pseudo-operations.

# The following are equivalent: CGetDefault $c1 CIncBase $c1, $c0, $zero

# The following are equivalent: CSetDefault $c1 CIncBase $c0, $c1, $zero

4.2.3 Capability Loads and Stores of Floating-Point ValuesThe current revision of the CHERI ISA does not have instructions for loading floating pointvalues directly via capabilities. MIPS does provide instructions for moving values betweeninteger and floating point registers, so a load or store of a floating point value via a capabilitycan be implemented in two instructions.

Four pseudo-instructions are defined to implement these patterns. These are clwc1 andcldc1 for loading 32-bit and 64-bit floating point values, and cswc1 and csdc1 as the equiv-alent store operations. The load operations expand as follows:

cldc1 $f7, $zero, 0($c2) # Expands to: cld $1, $zero, 0($c2) dmtc1 $1, $f7

Note that integer register $1 ($at) is used; this pseudo-op is unavailable if the noat direc-tive is used. The 32-bit variant (clwc1) has a similar expansion, using clwu and mtc1.

The store operations are similar:

107

csdc1 $f7, $zero, 0($c2) # Expands to: dmfc1 $1, $f7 csd $1, $zero, 0($c2)

The specified floating point value is moved from the floating point register to $at and thenstored using the correct-sized capability instruction.

108

Chapter 5

Design Rationale

During the design of CHERI, we considered many different capability architectures and designapproaches. This chapter describes the design choices that were made, briefly outlines somepossible alternatives, and provides a rationale for the choices that were made.

High-Level Design Approach: Capabilities as Pointers

Our goals of providing fine-grained memory protection and compartmentalization led to anearly design choice to approach capabilities as a form of pointer. This rapidly led to a numberof conclusions:

• Capabilities are within virtual address spaces, imposing an ordering in which capabilityprotections are evaluated before virtual-memory protections; this in turn had impliationsfor the hardware composition of the capability coprocessor and conventional MMU in-teract.

• Capabilities are treated by the compiler in much the same way as pointers, meaningthat they will be loaded, manipulated, dereferenced, and stored via registers and to/fromgeneral-purpose memory by explicit instructions, which we used modeled on similarconventional RISC instructions.

• Incremental deployment within programs meant that not all pointers would immediatelybe converted to capabilities, implying that both might coexist in the same memory; also,there was a strong desire to embed capabilities within data structures, rather than storethem in separate segments, requiring fine-granularity tagging.

• Incremental deployment and compatibility with the UNIX model implied retaining thegeneral-purpose memory management unit (MMU) pretty much as currently designed,including support for variable page size, TLB layout, etc. The MIPS ISA describes asoftware-managed TLB rather than hardware page-table walking as is present in mostother ISAs; this is not fundamental to our approach, and either model would work.

109

Capability-Register FileThe decision to separate the capability-register file from the general-purpose register file issomewhat arbitrary from a software-facing perspective: we envision capabilities gradually dis-placing general-purpose registers as pointers, but that management of the two register files willremain largely the same, stack spilling will behave the same way, and so on. We selected theseparate representation for a few pragmatic reasons:

• Coprocessor interfaces frequently make the assumption of additional register files (a lafloating-point registers).

• Capability registers are quite large, and by giving the capability coprocessor its ownpipeline for manipulations, we could avoid enforcing a 256-wide path through the mainpipeline.

• It is more obvious, given a coprocessor-based interface, how to provide compatibilitysupport in which the capability coprocessor is “disabled,” the default configuration inorder to support unmodified MIPS compilers and operating systems.

However, it is entirely possible to imagine a variation on the CHERI design in which, moresimilar to the manner in which the 32-bit x86 ISA was extended to support 64-bit registers,the two files were conflated and able to hold both general-purpose and capability registers.Early in our design cycle, capability registers were able to hold only true capabilities (i.e.,with tags); later, we weakened this requirement by adding an explicit tag bit to each register inorder to improve support for capability-oblivious code such as memory-copy routines able tocopy data structures consisting of both capabilities and ordinary data. This shifts our approachsomewhat more towards a conflated approach; our view is that efficiency if implementationand compatibility, rather than negligible effect on the software model, would be the primaryreasons to select one approach or another for a particular starting-point ISA.

Another design variation might have more tightly coupled specific capability registers withgeneral-purpose registers – an approach we discussed extensively, especially when comparingwith the bounds-checking literature which has explored techniques based on sidecar registersor associative look-aside buffers. Many of these approaches did not adopt tags as a meansof strong integrity protection, which we require for the compartmentalization model, makingassociative techniques less suitable. Further, we felt that the working-set properties of the tworegister files might be quite different, and effectively pinning the two to one another wouldreduce the efficiency of both.

It is worth considering, however, that our recent interest in cursors within capabilities re-visits both of these ideas.

Representation of Memory SegmentsCHERI capabilities represent a region of memory by its base address and length; memoryaccesses are relative to the base address. An alternative representation would have been forcapabilities to contain an upper and lower bound on addresses within the memory region, withmemory accesses being given in terms of absolute addresses but checked against the upper andlower bound.

110

The base and length representation was chosen because it is more convenient for arrays andstructures in the C language. Given a capability for an array and an index into the array, thearray element can be read with (for example) CLB without the need for an addition in software.(In C, all arrays are zero based. This is not the case in other languages, e.g. Ada). The lengthof a structure is usually known at compile time, and the length of a capability can be set to thelength of a structure with CSetLen; setting an upper bound would require a additional additioninstruction to compute it.

Although CHERI does not attempt to keep the base address of a capability secret, the use ofbase-relative (rather than absolute) addresses for memory accesses reduces the need to keep theabsolute base address of a capability in a general purpose register, and possibly might facilitatecode migration to a stricter version of the architecture in which absolute addresses are secret.

The disadvantages of the base and length representation are that:

• There is no way to grant access to the very last byte of the virtual address space (a baseof 0 and a length of 264 − 1 grants access to addresses 0 to 264 − 2).

• Base-relative addressing is cumbersome for code capabilities. If a program wants to calla subroutine, and to grant the subroutine execute access only to its own instructions andnot to the entire program text, then the subroutine needs to be linked differently from thecalling program, because branches within the subroutine will be relative to a differentbase.

A key concern with the current representation is its substantial size – simulation suggeststhat cache footprint is a dominant factor in performance, although optimization techniques suchas CCured would reduce this effect. We believe that a reduction to 128-bit capability registerswould come at an observable cost to both protection scalability (e.g., limiting the number of bitsin a pointer to 40-48 bits rather than the full 64) as well as compartmentalization functionality(e.g., having fewer software-defined permission bits). However, in practice this may provenecessary to support widespread adoption. Some care must be taken to retain current softwareflexibility, especially regarding very fine-grained regions of memory, which are highly desirableto support critical protection properties for C – e.g., granular stack protection and arbitrarysubdivision of character-based strings into separate bounded regions. It could be that pointercompression techniques eliding specific middle bits in the address space, or possibly tradingoff size and granularity (e.g., bits might be invested either in describing very small objects atarbitrary alignment, or very large objects at more coarse alignment) provide a useful middleground.

Signed and Unsigned OffsetsIn the CHERI instructions that take both a register offset and an immediate offset, the registeroffset is treated as unsigned integer but the immediate offset is treated as a signed integer.

Register offsets are treated as unsigned so that given a capability to the entire address space(except for the very last byte, as explained above), a register offset can be used to access anybyte within it. Signed register offsets would have the disadvantage that negative offsets wouldfail the capability bounds check, and memory at offsets within the capability greater than 263

would not be accessible.

111

Immediate offsets, on the other hand, are signed, because the C compiler often refers toitems on the stack using the stack pointer as register offset plus a negative immediate offset. Wehave already enountered observable difficulty due to a reduced number of bits available for im-mediate offsets in capability-relative memory operations when dealing with larger stack-framesizes; it is unclear what real performance cost this might have (if any), but does reemphasizethe importance of careful investment of encoding bits for instructions.

Overwriting Capabilities

In CHERI, if a capability in memory is partly overwritten with non-capability data, then thememory contents afterwards will be the capability converted to a byte representation and thenoverwritten.

Alternative designs would have been for the capability to be zeroed first before being over-written; or for the write to raise an exception (with an explicit “clear tag in memory” operationfor the case when a program really intends to overwrite a capability with non-capability data).

The chosen approach is simpler to implement in hardware. If store instructions neededto check the tag bit of the memory location that was being written, then they would need tohave a read-modify-write cycle to the memory, rather than just a write; in general, the MIPSarchitecture carefully avoids the need for a read-modify-write cycle within a single instruction.(Although, once the memory system needs to deal with cache coherence, a write is not thatmuch simpler than a read-modify-write).

The CHERI behavior also has the advantage that programs can write to a memory location(e.g., when spilling a register on to the stack) without needing to worry about whether thatlocation previously contained a capability or non-capability data.

A potential disadvantage is that the contents of capabilities cannot be kept secret froma program that uses them. A program can always discover the contents of a capability byoverwriting part of it, then reading the result as non-capability data. In CHERI, there are other,more direct, ways for a program to discover the contents of a capability it owns, so this is not asecurity vulnerability.

However, there are ABI concerns: we have tried to design the ISA in such a way that soft-ware does not need to be aware of the in-memory layout of capabilities, but as it is necessarilyexposed, there is a risk that software might become dependent on a specific layout. One case ofparticular note is in the operating-system paging code, which must save and restore capabilitiesand their tags separately; this can be accomplished by using instructions such as CGetBase onuntagged values loaded from disk and then refining an in-hand capability using CSetBase –an important reason not to limit capability field retrieval instructions to tagged values.

Reading Capabilities as Bytes

In CHERI, if a data load instruction such as CLB is used on a memory location containinga capability, the internal representation of the capability is read. An alternative architecturewould have such loads return zero, or raise an exception.

Because the contents of capabilities are not secret, allowing them to be read as raw data isnot a security vulnerability.

112

Capability registers are dynamically taggedIn CHERI, capability registers and memory locations have a tag bit that indicates whetherthey hold a capability or non-capability data. (An alternative architecture would give memorylocations a tag bit, where capability registers could contain only capabilities – with an exceptionraised if an attempt were made to load non-capability data into a capability register with CLC.)

Giving capability registers and memory locations a tag bit simplifies the implementationof cmemcpy(). cmemcpy() is a variant of memcpy() that copies the tag bit as well as thedata, and so can be used to copy structures containing capabilities. As capability registers aredynamically tagged, cmemcpy() can copy a structure by loading it into a capability registerand storing it to memory, without needing to know at compile time whether it is copying acapability or non-capability data.

Tag bits on capability registers may also be useful for dynamically typed languages in whicha parameter to a function can be (at run time) either a capability or an integer. cmemcpy() canbe regarded as a function whose parameter (technically a void ) is dynamically typed.

Separate Permissions for Storing Capabilities and DataCHERI has separate permission bits for storing a capability versus storing non-capability data.(And similarly, for loading a capability versus loading non-capability data).

(An alternative design would be just one Permit Load and just one Permit Store permissionthat were used for both capabilities and non-capability data.)

The advantage of separate permissions bits for capabilities is that that there can be two pro-tected subsystems that communicate via a memory buffer to which they have Permit Load andPermit Store permissions, but do not have Permit Load Capability or Permit Store Capability.Such communicating subsystems cannot pass capabilities via the shared buffer, even if theycollude. (We realized that this was potentially a requirement when trying to formally model thesecurity guarantees provided by CHERI).

Capabilities Do Not Contain a CursorIn the C language, pointers can be both incremented and decremented. C pointers are some-times used as a cursor that points to the current working element of an array, and is moved upand down as the computation progresses.

In contrast, the base of a CHERI capability can be incremented (via CIncBase) but notdecremented. When CHERI capabilities are used from C, a pointer with type attribute capability

can be incremented but not decremented.An alternative architecture would have included a “cursor” field within a capability, that

could be both incremented and decremented without changing base. This would have givencapability variables semantics that were closer to ordinary C pointers, at the expense of

making capabilities take up more space in memory, with a reduction in performance as a result.In comparison, the CCured language includes both FSEQ and SEQ pointers. CHERI capa-

bilities are analogous to CCured’s FSEQ pointers. Programming languages that need semanticssimilar to to CCured’s SEQ can be implemented on CHERI by compiling them as the pair of aCHERI capability and an integer that acts as a cursor into the array.

113

We are now actively exploring variations on the CHERI ISA that do implement tags inorder to improve source-code level compatibility. This turns out to be particularly critical forpacket-parsing code that will frequently perform a series of pointer operations and then vali-date the resulting pointer against a bound (often incorrectly); with CHERI as defined, invalidpointers cannot be constructed and such operations will generate an exception, or require com-piler support for coupling pointers with capabilities. As there is substantial space in the CHERIcapability – in particular, an unused entry address/type field intended for use with object ca-pabilities – introducing a cursor is relative straightforward, although obviously must be donewith care. The model we have prototyped allows the cursor to float freely outside of the boundsspecified by the capability base and length, generating an exception only if it is used to loadand store from disallowed addresses, tracking an invalid dereference. Separate instructions getand set the cursor, allowing current CHERI code to work unmodified, with CSetBase alsoadjusting the cursor.

NULL Has the Tag Bit Set

In some programming languages, pointer variables must always point to a valid object. In C,pointers can either point to an object or be NULL; by convention, NULL is the integer valuezero cast to a pointer type.

If hardware capabilities are used to implement a language that has NULL pointers, how isthe NULL pointer represented? CHERI capabilities have a tag bit; if the tag bit is set, a validcapability follows, otherwise the remaining data can be interpreted as (for example) bytes orintegers. The representation we have chosen for NULL is that the tag bit is set and the baseand length fields are zero; effectively, NULL is an array of length zero.

An alternative representation we have could have chosen for NULL would have been withthe tag bit unset, and zero in the base field; effectively, NULL would be the integer zero.

Many of the CHERI instructions are agnostic as to which of these two conventions forNULL is employed, but the CFtomPtr and CToPtr are aware of the convention.

One advantage of having NULL’s tag bit unset would have been that it would be possi-ble for code to conditionally branch on a capability being NULL by using the CBTS or CBTUinstruction.

One advantage of the convention we have chosen is that dynamically typed languages candistinguish between a pointer to a valid object, NULL, a non-zero integer and the integer zero.For example, a dynamically typed language could use capabilities with tag unset for smallintegers (including zero), capabilities with tag set pointing to an arbitrary precision integerfor large integers, and the NULL capability (tag unset, length zero) for an optional parameterbeing absent.

Permission Bits Determine the Type of a Capability

In CHERI, a capability’s permission bits together with the u bit determine what kind of capa-bility it is. A capability for a region of memory has u and Permit Load and/or Permit Storeset; a capability for an object has u unset and Permit Execute unset; a capability to call a pro-tected subsystem (a “call gate”) has u unset and Permit Execute set; a capability that allows the

114

owner to create objects whose type identifier (otype/eaddr) falls within a range has u unsetand Permit Set Type set.

An alternative architecture would have included a separate capability type field, as well asthe perms field, within each capability; the meaning of the rest of the bits in the capabilitywould have been dependent on the value of the capability type field.

A potential disadvantage of not having a capability type field is that different kinds ofcapability cannot use the remaining bits of the capability in different ways.

A consequence of the architecture we have chosen is that it is possible to create manydifferent kinds of capability (2 to the power of the number of permission bits plus u). Some ofthe kinds of capability that it is possible to create do not have a clear use case; they just exist asa consequence of the representation chosen for capabilities.

Object Types are AddressesIn CHERI, the otype/eaddr field serves both as a unique identifier for an object type and asthe address of the executable code that implements the methods on that object type.

An alternative architecture would have been to include separate fields within a capabilityfor the object type id and for the address of the code that implements the object’s methods.

The architecture we have chosen allows us to keep the size of capabilities small (which isimportant for performance) at the cost of some conceptual confusion caused by these multipleuses of the otype/eaddr field.

Treating the set of object type identifiers as being the same as the set of memory addresseshas the additional advantage that it simplifies assigning type identifiers to protected subsystem:each subsystem can use its start address as the unique identifier for the type it implements.Subsystems that need to implement multiple types, or create new types dynamically can begiven a capability with Permit Set Type set for a range of memory addresses, and they arethen able to use types within that range. This avoids the need for some sort of privilegedtype manager that creates new type identifiers; such a type manager is potentially a source ofcovert channels. (Suppose that there was a type manager and it allocated type identifiers innumerically ascending order. A subsystem that asks the type manager twice for a new typeid and gets back n and n + 1 knows that no other subsystem has asked for a new type id inbetween the two calls; this could in principle be used for covert communication between twosubsystems that were supposed to be kept isolated by the capability mechanism).

Unseal is an Explicit OperationIn CHERI, converting a pointer to an opaque object into a pointer that allows the object’scontents to be inspected or modified directly is an explicit operation. It can be done directlywith the CUnseal operation, or by using CCall to run the result of unsealing the first argumenton the result of unsealing the second argument.

An alternative architecture would have been one with “implicit” unsealing, where a sealedcapability (u clear) could be dereferenced without explicitly unsealing it first, provided that thesubsystem attempting the dereference had some kind of ambient authority that permitted it todeference sealed capabilities of that type. This ambient authority could have taken the form ofa protection ring or the otype/eaddr field of PCC.

115

The disadvantage of the architecture we have chosen is that protected subsystems need tobe careful not to leak capabilities that they have unsealed, for example by leaving them onthe stack when they return to their caller. In an architecture with “implicit unseal”, protectedsubsystems would just need to delete their ambient authority for the type before returning, andwould not need to explicitly clean up all the unsealed capabilities that they had created.

116

Chapter 6

CHERI in Programming Languages andOperating Systems

We capture some of our early thoughts on the topic of use of CHERI instructions in program-ming languages and operating systems. The goal of our software work is to test several funda-mental hypotheses underlying the CHERI architecture:

• That a hardware capability model provides superior performance when large numbers ofprotection domains are required.

• That protection domains within address spaces offer improved programmability and de-buggability for compartmentalized TCB components.

• That there are (fairly) natural mappings from higher-level language pointer and referencemodels into memory-capability semantics.

• That capability adaptation of common TCB components offers dramatically improvedrobustness and security.

• That a hardware capability model and MMU-based virtual addressing can not only coex-ist, but also facilitate an adoption of capability approaches – offering both an incrementaladoption path with immediate security benefits and a long-term vision for software secu-rity improvement.

• That a fully virtualizable per-address-space capability system is feasible and practical,while allowing use of capability models within individual hierarchical rings and addressspaces.

To this end, we are developing a significant software stack that will utilize the CHERI featureset, implementing and exercising various aspects of the hybrid capability model.

6.1 Development Plan and StatusAt the time of writing, we are roughly three and one-half years into a five-year research projectin hardware and software security. We have successfully prototyped a fully pipelined 64-bitCPU implementing the 64-bit MIPS and CHERI ISAs; detailed information on this prototype

117

can be found in the accompanying BERI Hardware Reference. The following sections docu-ment our recent accomplishments and continuing strategy for exploring the software implica-tions of the CHERI architecture.

6.2 Open-Source Foundations

During the initial bring-up phase of our prototype CHERI CPU, CHERI’s support for incre-mental adoption has proven invaluable: we will be able to rely on current open source bootloaders, operating systems, programming languages, compilers, debuggers, and applications,to selectively deploy capability features in the most critical software foundations and the mostvulnerable services.

6.3 Current Software Implementation

We have extended existing 64-bit MIPS versions of FreeBSD operating system, GNU assem-bler, and LLVM/Clang compiler suite to support CHERI ISA features.

6.4 CheriBSD

We have extended the existing 64-bit MIPS port of FreeBSD to support a range of Altera/Tera-sic hardware peripherals, and our CHERI ISA extensions. CheriBSD maintains a coprocessor2 context for each user thread; it implements CCall/CReturn exception handlers, and recoverypaths for when a sandbox triggers a hardware exception (e.g., due to an invalid memory refer-ence). CheriBSD includes a new libcheri which implements a sandbox API and a growing setof system services that may be delegated to sandboxed code.

6.4.1 Extended GNU Assembler (gas)

We have extended the GNU assembler (gas) to support the CHERI ISA, by allowing assemblyfiles, and an inline assembler from C to make use of CHERI instructions. Tools such as ob-jdump are also able to interpret CHERI instructions. We have not yet extended the linker tosupport new CHERI-related linkage types; instead, we rely on hybrid behavior to implementprograms for the time being.

6.5 Extended LLVM/Clang

LLVM is a framework for implementing compilers that comprises a well-defined intermediaterepresentation (IR), a set of APIs for generating this representation, optimization passes fortransforming it, and back ends for generating native code. We have extended the MIPS backend in LLVM to provide support for capability instructions.

118

We reserve address space 2001 for capability pointers. Any pointer to address space 200 isassumed to be a capability. We also add explicit integer to pointer and pointer to integer patternsin the back end. These are required because all existing LLVM back ends regard pointers andintegers as interchangeable.

The LLVM back end also provides an alternative assembler. This currently lacks someMIPS instructions, so is not yet a replacement for the GNU assembler, but does provide supportfor both inline assembly and for stand-alone assembly files.

The modifications to LLVM are intended to make experimentation with programming lan-guages easier. Any language front end that can generate LLVM IR can be modified to supportcapabilities and we are free to experiment with new languages and modifications to others.

In addition to the support for capabilities as pointers, we also provide a number of intrinsicsthat map closely to instructions. The example below uses the llvm.cheri.set.cap.lengthintrinsic, which sets the length of a capability. This example shows the LLVM IR for a simplefunction that wraps the C standard malloc() in one that returns a capability that will enforce thelength.

define i8 addrspace(200)* @cmalloc(i64 %s) nounwind { entry: ; Call malloc() %call = tail call i8* @malloc(i64 %s) nounwind ; Convert the C0-relative pointer to a capability %0 = ptrtoint i8* %call to i64 %1 = inttoptr i64 %0 to i8 addrspace(200)* ; CSetLen %2 = tail call i8 addrspace(200)* @llvm.cheri.set.cap.length(i8

addrspace(200)* %1, i64 %s) ret i8 addrspace(200)* %2 }

Clang is a front end for LLVM that generates LLVM IR from C-family languages (C, C++,Objective-C, and Objective-C++). Our first work on language extensions involves providingcapability support to C. Programmers can annotate pointers as being capabilities, which triggersCHERI rather than MIPS code generation for any resulting memory accesses. C-language typessuch as const now perform dynamic permission refinement. We have an experimental versionof the same compiler code that now supports stack access via capability.

Objective-C provides a late-bound object oriented model on top of C that makes it an inter-esting test ground for experimentation. Combined with the MIT-licensed GNUstep Objective-Cruntime, we can experiment with adding language features to Objective-C based on our exten-sions to C.

6.5.1 Extended CHERI Unit-Test Suite

Using the CHERI assembler, we have extended our existing MIPS ISA test suite to exercizevarious aspects of the CHERI ISA. The current test suite validates the behavior of memory

1The number 200 is subject to change and should not be relied on. Address spaces under 256 are intended tobe reserved for architecture-agnostic uses, so we may either move this to a higher number, or retain a low numberas a general fat-pointer address space in LLVM IR.

119

capabilities and capability exceptions, including monotonic decrease in rights using capabil-ity manipulation instructions. More detailed implementation status for the CHERI hardwareprototype may be found in the BERI Hardware Reference.

6.6 Future PlansBetween 2010 and 2014, we completed basic prototyping of the CHERI hardware and softwareplatform. We are now considering potential future directions for further hardware and softwareexperimentation, including bindings to higher-level languages such as Objective-C, OCaml,and Java. We are also exploring how adding capability support to LLDB and the LLVM de-bugger would allow us to develop capability-aware programs, as well as considering securityimplications for designing and implementing debuggers.

120

Chapter 7

Future Directions

The CTSRD project, of which CHERI is just one element, has now been in progress for threeand a half years. Our focuses to date have been in several areas:

1. Design the CHERI instruction set architecture based on a hybrid object-capability model.As part of this work, develop a PVS formal model of the ISA, and analyze propertiesabout program expressivity.

2. Flesh out the ISA feature set in CHERI to support a real-world operating system – primar-ily, this has consisted of adding support for the system management coprocessor, CP0,which includes the MMU and exception model, but also features such as a programmableinterrupt controller (PIC). We have also spent considerable time refining a second versionof the ISA intended to better support automatic compilation, which is now implemented.

3. Prototype, test, and refine CHERI ISA extensions, which are incorporated via a newcapability coprocessor, CP2.

4. Port the FreeBSD operating system first to a capability-free version of CHERI, known asBERI. This is known as FreeBSD/BERI.

5. Adapt FreeBSD to make use of CHERI features – first by adapting the kernel to maintainnew state and provide object invocation, and then low-level system runtime elements,such as the system library and runtime linker. This is known as CheriBSD.

6. Adapt the Clang/LLVM compiler suite to be able to generate CHERI ISA instructions asdirected by C-language annotations.

7. Begin to develop semi-automated techniques to assist software developers in compart-mentalizing applications using Capsicum and CHERI features. This is a subprojectknown as Security-Oriented Analysis of Application Programs (SOAAP), and performedin collaboration with Google.

8. Develop FPGA-based demonstration platforms, including an early prototype on the Tera-sic tPad, and more mature server-style and tablet-style prototypes based on the TerasicDE4 board. We have also made use of CHERI2 on the NetFGPA 10G board.

121

9. Develop techniques for translating Bluespec hardware designs into PVS representationsso that they can be used for formal analysis purposes. The SRI PVS tool suite has beenembedded in the BluespecVerilog compiler chain to enable formal verification, modelchecking (SAL), and SMT solving (Yices) inline with the compilation.

We have made a strong beginning, but clearly there is much to do. From this vantage point, wesee a number of tasks ahead, which we detail in the next few sections.

7.1 An Open-Source Research ProcessorOne of our goals for the CHERI processor is to produce a reference Bluespec processor im-plementation, which can then be used as a foundation not only for CHERI, but also for otherresearch projects in the hardware-software interface. Capability processor extensions to theMIPS ISA would then be a core research result from this project, but also the first example ofresearch conducted on the reference processor.

We have spent a considerable amount of time preparing CHERI for open sourcing, includingenhancing our test suite, updating documentation, and preparing a new open-source licenseintended for hardware-software projects (derived from the Apache software license).

7.2 Formal Methods for BluespecWe have created prototype descriptions of the CHERI ISA in PVS and SAL, and are collabo-rating with the REMS project at Cambridge to develop an L3 model of the MIPS ISA, with theintent of also applying it to CHERI. We have used our formal models to automatically generatetest suites, and to prove higher-level properties about what the ISA can represent. We have cre-ated new tools to automatically process Bluespec designs for use in theorem proving and modelchecking, and developed new tools to improve SMT performance and to extract higher-levelproperties from hardware designs. Our longer-term goal is to link formal models of the hard-ware itself with the ISA specification and software compiled to that ISA. We hope that, by thecompletion of the CTSRD project, we will also be able to prove a number of basic but interest-ing properties about the hardware design, such as correctness of pipelining and the capabilitycoprocessor. Perhaps we may even be able to extend the formal analysis into the lower-layersystem software – such as properties relating to capability-based protection in sandboxing andcompiling.

7.3 ABI and Compiler DevelopmentWe have targeted our CHERI ISA extensions at compiler writers, rather than for direct use byapplication authors. This has required us to design new Application Binary Interfaces (ABIs),and to extend the C programming language to allow specification of protection properties byprogrammers. We have extended the GNU assembler and the Clang/LLVM compiler suiteto generate CHERI instructions, and begun to experiment with modifications to applications.We anticipate significant future work in this area to validate our current approach, but also toextend these ideas both in C and other programming languages, such as Objective C. We are

122

also interested in CHERI instructions as a target for just-in-time compilation by systems suchas Dalvik.

7.4 Hardware Capability Support for FreeBSDWith a capability processor prototype complete, and a FreeBSD/BERI port up and running,we have begun an investigation into adding CHERI capability support to the operating sys-tem. Currently, the CheriBSD kernel is able to maintain additional per-thread CHERI state foruser processes via minor extensions to the process and thread structures, as well as exception-handling code. We have also prototyped object-capability invocation, which we are in theprocess of integrating with the operating system. A number of further tasks remain, includ-ing adding memory tag support to paging and swapping, enhancing TLB support to includeCHERI-related flags, and continuing to adapt userspace OS components, such as the systemlibrary and runtime linker, to use CHERI capability features. This work depends heavily onClang/LLVM support for capabilities.

We need to explore security semantics for the kernel to limit access to kernel services (espe-cially system calls) from sandboxed userspace code. This will require developing our notionsof privilege described in Chapter 2; the userspace runtime and kernel must agree on which ser-vices (if any) are available without passing through a trusted protected subsystem, such as theruntime linker.

Ideally, the kernel should make use of capabilities, initially for bounded memory buffers(offering protection against kernel buffer overflows, for example), but later protected subsys-tems. An iterative refinement of hardware and software privilege models will be required: forexample, a sandboxed kernel subsystem should not be able to modify the TLB without goingthrough a kernel protected subsystem, meaning that simple ring-based notions of privilege forMMU access are insufficient.

7.5 Evaluating Performance and ProgrammabilityThis report describes a fundamental premise: that through an in-address space capability model,performance and programmability for compartmentalized applications can be dramatically im-proved. Once the capability coprocessor and initial programming language, toolchain, andoperating system support come together, validating this claim will be critical. We anticipatemaking early efforts to apply compartmentalization to base system components: elements ofthe operating system kernel, critical userspace libraries, and critical userspace applications.

Our hybrid capability architecture will ease this experimentation, making it possible toapply, for example, capabilities within zlib without modifying an application as a whole.Similarly, capability-aware applications should be able to invoke existing library services, evenfiltering their access to OS services – a similarly desirable hypothesis to test.

We are concerned not only with whether we can express the desired security properties,but also compare their performance with MMU-based compartmentalization, such as that de-veloped in the Capsicum project. An early element of this work will certainly include testingof security context-switch speed as the number of security domains increases, in order to con-firm our hypothesis regarding TLB size and highly compartmentalized software, but also thatcapability context switching can be made orders of magnitude faster as software size scales.

123

124

Bibliography

[1] M. Accetta, R. Baron, D. Golub, R. Rashid, A. Tevanian, and M. Young. Mach: ANew Kernel Foundation for UNIX Development. Technical report, Computer ScienceDepartment, Carnegie Mellon University, August 1986.

[2] W. B. Ackerman and W. W. Plummer. An implementation of a multiprocessing computersystem. In SOSP ’67: Proceedings of the First ACM Symposium on Operating SystemPrinciples, pages 5.1–5.10, New York, NY, USA, 1967. ACM.

[3] J. Anderson. Computer security technology planning study. Technical Report ESD-TR-73-51, U.S. Air Force Electronic Systems Division, October 1972. (Two volumes).

[4] G. R. Andrews. Partitions and principles for secure operating systems. Technical report,Cornell University, Ithaca, NY, USA, 1975.

[5] Apple Inc. Mac OS X Snow Leopard. http://www.apple.com/macosx/, 2010.

[6] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. E. Fiuczynski, D. Becker, C. Cham-bers, and S. Eggers. Extensibility safety and performance in the SPIN operating system.In SOSP ’95: Proceedings of the Fifteenth ACM Symposium on Operating Systems Prin-ciples, pages 267–283, New York, NY, USA, 1995. ACM.

[7] R. Bisbey II and D. Hollingworth. Protection Analysis: Project final report. Technicalreport, USC Information Sciences Institute (ISI), Marina Del Rey, California, 1978.

[8] A. Bittau, P. Marchenko, M. Handley, and B. Karp. Wedge: Splitting Applications intoReduced-Privilege Compartments. In Proceedings of the 5th USENIX Symposium onNetworked Systems Design and Implementation, pages 309–322. USENIX Association,2008.

[9] M. Branstad and J. Landauer. Assurance for the Trusted Mach operating system. InProceedings of the Fourth Annual Conference on Computer Assurance COMPASS ’89,pages 9–13. IEEE, June 1989.

[10] B. M. Cantrill, M. W. Shapiro, and A. H. Leventhal. Dynamic instrumentation of produc-tion systems. In ATEC ’04: Proceedings of the USENIX Annual Technical Conference,Berkeley, CA, USA, 2004. USENIX Association.

[11] E. Cohen and D. Jefferson. Protection of the Hydra operating system. In Proceedings ofthe Fifth ACM Symposium on Operating Systems Principles, pages 141–160, 1975.

125

http://www.apple.com/macosx/

[12] F. J. Corbato, M. Merwin-Daggett, and R. C. Daley. An experimental time-sharing system.In AIEE-IRE ’62 (Spring): Proceedings of the May 1–3, 1962, Spring Joint ComputerConference, pages 335–344, New York, NY, USA, 1962. ACM.

[13] F. J. Corbato and V. A. Vyssotsky. Introduction and overview of the Multics system. InAFIPS ’65 (Fall, part I): Proceedings of the November 30–December 1, 1965, Fall JointComputer Conference, part I, pages 185–196, New York, NY, USA, 1965. ACM.

[14] R. C. Daley and P. G. Neumann. A general-purpose file system for secondary storage. InAFIPS Conference Proceedings, Fall Joint Computer Conference, pages 213–229. Spar-tan Books, November 1965.

[15] P. J. Denning. Fault tolerant operating systems. ACM Computing Surveys, 8(4):359–389,1976.

[16] J. B. Dennis and E. C. Van Horn. Programming semantics for multiprogrammed compu-tations. Communications of the ACM, 9(3):143–155, 1966.

[17] P. Efstathopoulos, M. Krohn, S. VanDeBogart, C. Frey, D. Ziegler, E. Kohler,D. Mazieres, F. Kaashoek, and R. Morris. Labels and event processes in the asbestosoperating system. SIGOPS Oper. Syst. Rev., 39:17–30, October 2005.

[18] R. S. Fabry. The case for capability based computers (extended abstract). In SOSP ’73:Proceedings of the Fourth ACM Symposium on Operating System Principles, page 120,New York, NY, USA, 1973. ACM.

[19] R. J. Feiertag and P. G. Neumann. The foundations of a Provably Secure Operating System(PSOS). In Proceedings of the National Computer Conference, pages 329–334. AFIPSPress, 1979. http://www.csl.sri.com/neumann/psos.pdf.

[20] P. G.Neumann, R. Boyer, R. Feiertag, K. Levitt, and L. Robinson. A Provably SecureOperating System: The system, its applications, and proofs. Technical Report CSL-116,Second edition, Computer Science Laboratory, SRI International, Menlo Park, California,May 1980.

[21] L. Gong. Inside Java(TM) 2 Platform Security: Architecture, API Design, and Implemen-tation. Addison-Wesley, Reading, Massachusetts, 1999.

[22] L. Gong, M. Mueller, H. Prafullchandra, and R. Schemers. Going beyond the sandbox: Anoverview of the new security architecture in the Java Development Kit 1.2. In Proceedingsof the USENIX Symposium on Internet Technologies and Systems, Monterey, California,December 1997.

[23] J. Gosling, B. Joy, and G. L. Steele. The Java Language Specification. Addison-WesleyLongman Publishing Co., Inc., Boston, MA, USA, 1996.

[24] R. Graham. Protection in an information processing utility. Communications of the ACM,11(5), May 1968.

[25] N. Hardy. KeyKOS architecture. SIGOPS Operating Systems Review, 19(4):8–25, 1985.

126

http://www.csl.sri.com/neumann/psos.pdf

[26] T. Jim, J. G. Morrisett, D. Grossman, M. W. Hicks, J. Cheney, and Y. Wang. Cyclone: Asafe dialect of C. In ATEC ’02: Proceedings of the USENIX Annual Technical Conference,pages 275–288, Berkeley, CA, USA, 2002. USENIX Association.

[27] A. Jones and W. Wulf. Towards the design of secure systems. In Protection in Op-erating Systems, Proceedings of the International Workshop on Protection in OperatingSystems, pages 121–135, Rocquencourt, Le Chesnay, France, 13–14 August 1974. Institutde Recherche d’Informatique.

[28] P. Karger. Limiting the damage potential of discretionary Trojan horses. In Proceedingsof the 1987 Symposium on Security and Privacy, pages 32–37, Oakland, California, April1987. IEEE Computer Society.

[29] P. Karger and R. Schell. Multics security evaluation: Vulnerability analysis. In Proceed-ings of the 18th Annual Computer Security Applications Conference (ACSAC), ClassicPapers section, Las Vegas, Nevada, December 2002. Originally available as U.S. AirForce report ESD-TR-74-193, Vol. II, Hanscomb Air Force Base, Massachusetts.

[30] P. A. Karger. Using registers to optimize cross-domain call performance. SIGARCHComputer Architecture News, 17(2):194–204, 1989.

[31] G. Klein, J. Andronick, K. Elphinstone, G. Heiser, D. Cock, P. Derrin, D. Elkaduwe,K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and S. Winwood. sel4:formal verification of an operating-system kernel. Communications of the ACM, 53:107–115, June 2009.

[32] A. Kwon, U. Dhawan, J. M. Smith, T. F. Knight, Jr., and A. DeHon. Low-fat pointers:Compact encoding and efficient gate-level implementation of fat pointers for spatial safetyand capability-based security. In 20th ACM Conference on Computer and Communica-tions Security, November 2013.

[33] B. Lampson. Redundancy and robustness in memory protection. In Information Process-ing 74 (Proceedings of the IFIP Congress 1974), volume Hardware II, pages 128–132.North-Holland, Amsterdam, 1974.

[34] B. W. Lampson. Dynamic protection structures. In AFIPS ’69 (Fall): Proceedings of theNovember 18-20, 1969, Fall Joint Computer Conference, pages 27–38, New York, NY,USA, 1969. ACM.

[35] B. W. Lampson. Protection. SIGOPS Operating Systems Review, 8(1):18–24, 1974.

[36] C. Lattner and V. Adve. LLVM: A compilation framework for lifelong program analy-sis and transformation. In Proceedings of the international symposium on code genera-tion and optimization: feedback-directed and runtime optimization, CGO ’04, pages 75–,Washington, DC, USA, 2004. IEEE Computer Society.

[37] N. G. Leveson and W. Young. An integrated approach to safety and security basedon system theory. Communications of the ACM, 57(2):31–35, February 2014. url-http://www.csl.sri.com/neumann/insiderisks.html.

127

[38] H. M. Levy. Capability-Based Computer Systems. Butterworth-Heinemann, Newton,MA, USA, 1984.

[39] J. Liedtke. On microkernel construction. In SOSP’95: Proceedings of the 15th ACMSymposium on Operating System Principles, Copper Mountain Resort, CO, Dec. 1995.

[40] S. B. Lipner, W. A. Wulf, R. R. Schell, G. J. Popek, P. G. Neumann, C. Weissman, andT. A. Linden. Security kernels. In AFIPS ’74: Proceedings of the May 6-10, 1974,National Computer Conference and Exposition, pages 973–980, New York, NY, USA,1974. ACM.

[41] S. McCanne and V. Jacobson. The BSD packet filter: a new architecture for user-levelpacket capture. In USENIX’93: Proceedings of the USENIX Winter 1993 Conference,Berkeley, CA, USA, 1993. USENIX Association.

[42] E. McCauley and P. Drongowski. KSOS: The design of a secure operating system. InNational Computer Conference, pages 345–353. AFIPS Conference Proceedings, 1979.Vol. 48.

[43] M. K. McKusick and G. V. Neville-Neil. The Design and Implementation of the FreeBSDOperating System. Pearson Education, 2004.

[44] A. Mettler and D. Wagner. Class properties for security review in an object-capabilitysubset of Java. In PLAS ’10: Proceedings of the 5th ACM SIGPLAN Workshop on Pro-gramming Languages and Analysis for Security, pages 1–7, New York, NY, USA, 2010.ACM.

[45] M. S. Miller. Robust composition: towards a unified approach to access control andconcurrency control. PhD thesis, Johns Hopkins University, Baltimore, MD, USA, 2006.

[46] M. S. Miller, M. Samuel, B. Laurie, I. Awad, and M. Stay. Caja: Safe active content in san-itized javascript, May 2008. http://google-caja.googlecode.com/files/caja-spec-2008-06-07.pdf.

[47] J. H. Morris, Jr. Protection in programming languages. Communications of the ACM,16(1):15–21, 1973.

[48] A. C. Myers and B. Liskov. A decentralized model for information flow control. SIGOPSOper. Syst. Rev., 31:129–142, October 1997.

[49] G. C. Necula and P. Lee. Safe kernel extensions without run-time checking. In OSDI’96: Proceedings of the Second USENIX symposium on Operating Systems Design andImplementation, pages 229–243, New York, NY, USA, 1996. ACM.

[50] P. G. Neumann. Holistic systems. ACM Software Engineering Notes, 31(6):4–5, Novem-ber 2006.

[51] P. G. Neumann, R. Boyer, R. Feiertag, K. Levitt, and L. Robinson. A Provably SecureOperating System: The system, its applications, and proofs. Technical report, ComputerScience Laboratory, SRI International, Menlo Park, California, May 1980. 2nd edition,Report CSL-116.

128

http://google-caja.googlecode.com/files/caja-spec-2008-06-07.pdf

http://google-caja.googlecode.com/files/caja-spec-2008-06-07.pdf

[52] P. G. Neumann and R. J. Feiertag. PSOS revisited. In Proceedings of the 19th An-nual Computer Security Applications Conference (ACSAC 2003), Classic Papers sec-tion, pages 208–216, Las Vegas, Nevada, December 2003. IEEE Computer Society.http://www.acsac.org/ and http://www.csl.sri.com/neumann/psos03.pdf.

[53] P. G. Neumann and R. N. Watson. Capabilities Revisied: A Holistic Approach to Bottom-to-Top Assurance of Trustworthy Systems. In Proceedings of the Fourth Annual LayeredAssurance Workshop, 2010.

[54] E. Organick. The Multics System: An Examination of Its Structure. MIT Press, Cam-bridge, Massachusetts, 1972.

[55] D. A. Patterson and C. H. Sequin. RISC I: A Reduced Instruction Set VLSI Computer.In ISCA ’81: Proceedings of the 8th Annual Symposium on Computer Architecture, pages443–457, Los Alamitos, CA, USA, 1981. IEEE Computer Society Press.

[56] N. Provos, M. Friedl, and P. Honeyman. Preventing Privilege Escalation. In Proceedingsof the 12th USENIX Security Symposium. USENIX Association, 2003.

[57] R. Rashid and G. Robertson. Accent: A communications oriented network operatingsystem kernel. In Proceedings of the Eighth ACM Symposium on Operating System Prin-ciples, pages 64–75, Asilomar, California, December 1981. (ACM Operating SystemsReview, Vol. 15, No. 5).

[58] C. Reis and S. D. Gribble. Isolating web programs in modern browser architectures. InEuroSys ’09: Proceedings of the 4th ACM European Conference on Computer Systems,pages 219–232, New York, NY, USA, 2009. ACM.

[59] D. Remy and J. Vouillon. Objective ML: a simple object-oriented extension of ML. InPOPL ’97: Proceedings of the 24th ACM SIGPLAN-SIGACT Symposium on Principlesof Programming Languages, pages 40–53, New York, NY, USA, 1997. ACM.

[60] D. M. Ritchie and K. Thompson. The UNIX time-sharing system. Communications ofthe ACM, 17(7):365–375, 1974.

[61] Ruby Users Group. Ruby Programming Language. http://www.ruby-lang.org/, October 2010.

[62] J. Rushby. The design and verification of secure systems. In Proceedings of the EighthACM Symposium on Operating System Principles, pages 12–21, Asilomar, California,December 1981. (ACM Operating Systems Review, 15(5)).

[63] J. Saltzer. Protection and the control of information sharing in Multics. Communicationsof the ACM, 17(7):388–402, July 1974.

[64] J. Saltzer and M. Schroeder. The protection of information in computer systems. Pro-ceedings of the IEEE, 63(9):1278–1308, September 1975.

[65] W. Schiller. The design and specification of a security kernel for the PDP-11/45. TechnicalReport MTR-2934, Mitre Corporation, Bedford, Massachusetts, March 1975.

129

http://www.ruby-lang.org/

http://www.ruby-lang.org/

[66] M. D. Schroeder. Engineering a security kernel for Multics. In SOSP ’75: Proceedingsof the Fifth ACM Symposium on Operating Systems Principles, pages 25–32, New York,NY, USA, 1975. ACM.

[67] E. J. Sebes. Overview of the architecture of Distributed Trusted Mach. In Proceedings ofthe USENIX Mach Symposium, pages 20–22. USENIX Association, November 1991.

[68] J. Shapiro, J. Smith, and D. Farber. EROS: a fast capability system. In SOSP ’99: Pro-ceedings of the seventeenth ACM Symposium on Operating Systems Principles, Dec 1999.

[69] R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau. The Flasksecurity architecture: System support for diverse security policies. In Proceedings of the8th USENIX Security Symposium, pages 123–139, Washington, D.C., USA, Aug. 1999.USENIX Association.

[70] R. Wahbe, S. Lucco, T. E. Anderson, and S. u. L. Graham. Efficient software-based faultisolation. In SOSP ’93: Proceedings of the Fourteenth ACM Symposium on OperatingSystems Principles, pages 203–216, New York, NY, USA, 1993. ACM.

[71] B. J. Walker, R. A. Kemmerer, and G. J. Popek. Specification and verification of theUCLA Unix security kernel. Communications of the ACM, 23(2):118–131, 1980.

[72] S. T. Walker. The advent of trusted computer operating systems. In AFIPS ’80: Proceed-ings of the May 19-22, 1980, national computer conference, pages 655–665, New York,NY, USA, 1980. ACM.

[73] H. J. Wang, C. Grier, A. Moshchuk, S. T. King, P. Choudhury, and H. Venter. The multi-principal OS construction of the Gazelle web browser. In Proceedings of the 18th USENIXSecurity Symposium, pages 417–432, Berkeley, CA, USA, 2009. USENIX Association.

[74] R. N. Watson, P. G. N. J. Woodruff, J. Anderson, R. Anderson, N. Dave, B. Laurie, S. W.Moore, S. J. Murdoch, P. Paeps, M. Roe, and H. Saidi. CHERI: a research platformdeconflating hardware virtualization and protection. In Runtime Environments, Systems,Layering and Virtualized Environments (RESoLVE 2012), 2012.

[75] R. N. M. Watson. New Approaches to Operating System Security Extensibility. Technicalreport, Ph.D. Thesis, University of Cambridge, Cambridge, UK, October 2010.

[76] R. N. M. Watson, J. Anderson, B. Laurie, and K. Kennaway. Capsicum: Practical ca-pabilities for Unix. In Proceedings of the 19th USENIX Security Symposium. USENIX,August 2010.

[77] R. N. M. Watson, D. Chisnall, B. Davis, W. Koszek, S. W. Moore, S. J. Murdoch, P. G.Neumann, and J. Woodruff. Bluespec Extensible RISC Implementation (BERI): SoftwareReference. Technical Report UCAM-CL-TR-853, University of Cambridge, ComputerLaboratory, 15 JJ Thomson Avenue, Cambridge CB3 0FD, United Kingdom, phone +441223 763500, 2014.

130

[78] R. N. M. Watson, D. Chisnall, B. Davis, W. Koszek, S. W. Moore, S. J. Murdoch, P. G.Neumann, and J. Woodruff. Capability Hardware Enhanced RISC Instructions (CHERI):User’s guide. Technical Report UCAM-CL-TR-851, University of Cambridge, ComputerLaboratory, 15 JJ Thomson Avenue, Cambridge CB3 0FD, United Kingdom, phone +441223 763500, 2014.

[79] R. N. M. Watson, P. G. Neumann, J. Woodruff, J. Anderson, D. Chisnall, B. Davis, B. Lau-rie, S. W. Moore, S. J. Murdoch, and M. Roe. Capability Hardware Enhanced RISC In-structions (CHERI): Instruction-Set Architecture. Technical Report UCAM-CL-TR-850,University of Cambridge, Computer Laboratory, 15 JJ Thomson Avenue, Cambridge CB30FD, United Kingdom, phone +44 1223 763500, 2014.

[80] R. N. M. Watson, J. Woodruff, D. Chisnall, B. Davis, W. Koszek, A. T. Markettos, S. W.Moore, S. J. Murdoch, P. G. Neumann, R. Norton, and M. Roe. Bluespec ExtensibleRISC Implementation (BERI): Hardware Reference. Technical Report UCAM-CL-TR-852, University of Cambridge, Computer Laboratory, 15 JJ Thomson Avenue, CambridgeCB3 0FD, United Kingdom, phone +44 1223 763500, 2014.

[81] M. Wilkes and R. Needham. The Cambridge CAP Computer and Its Operating System.Elsevier North Holland, New York, 1979.

[82] 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 RISCin an age of risk. In Proceedings of the 41st International Symposium on ComputerArchitecture (ISCA 2014), 2014.

[83] W. Wulf, E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, and F. Pollack. HYDRA:the kernel of a multiprocessor operating system. Communications of the ACM, 17(6):337–345, 1974.

[84] W. Wulf, R. Levin, and S. Harbison. Hydra/C.mmp: An Experimental Computer System.McGraw-Hill, New York, 1981.

[85] 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. InProceedings of the 2009 30th IEEE Symposium on Security and Privacy, pages 79–93,Washington, DC, USA, 2009. IEEE Computer Society.

[86] B. Yee, D. Sehr, G. Dardyk, J. B. Chen, R. Muth, T. Ormandy, S. Okasaka, N. Narula, andN. Fullagar. Native client: A sandbox for portable, untrusted x86 native code. In SP ’09:Proceedings of the 2009 30th IEEE Symposium on Security and Privacy, pages 79–93,Washington, DC, USA, 2009. IEEE Computer Society.

[87] N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazieres. Making information flowexplicit in histar. In Proceedings of the 7th symposium on Operating systems designand implementation, OSDI ’06, pages 263–278, Berkeley, CA, USA, 2006. USENIXAssociation.

131

Date post:	11-Feb-2017
Category:	Documents
Upload:	lynhan
View:	218 times
Download:	1 times

Capability Hardware Enhanced RISC Instructions: CHERI Instruction ...

Documents