Current CPU architectures provide only weak support for software segmentation, a key underpinning for software security techniques such as sandboxing, managed languages, and static analysis. Because hardware memory segmentation is relevant mainly in the program abstraction its support has been deemphasized in modern operating systems, yet modern hardware requires operating system support to use its segmentation features. This paper argues that by implementing a capability model, it is possible to safely support creation, distribution and use of segments purely in user space. Hardware support for user-mode segmentation would enable e cient sandboxing within processes, enforcement of compiler structure, managed languages, and formal veri cation of machine code. We present a working prototype of such a system implemented on an FPGA and running FreeBSD.
2.1
ments, allowing them to protect and relocate program modules [
Intel's IA-32 instruction set demonstrates this historical pattern. The Intel 286 was the rst Intel x86 processor
to support memory protection [
While strict programming languages and managed runtimes have been su cient to ensure a level of working
correctness, both have shown cracks when facing intentional exploitation [
Maintaining security in the face of a global collection of capable adversaries requires very strong correctness of security mechanisms. While securing individual client computers does not automatically make a network secure, many network intrusions begin with a violation of a client's memory protection. A comprehensive hardware segmentation system would make direct, automatic and continual protection of objects in memory available to compilers and runtimes to improve performance and simplify enforcement. 2.3
In 1966 Computer Science began to clearly discuss a cohesive, decentralized system for program correctness
and security [
A segment mechanism that implements the capability model of safe, programmatic memory protection should have three properties: { All memory accesses must be via segments. { The program must be able to restrict its segments but not expand them. { The program must be able to pass control between domains possessing di erent segments without granting additional segments to either domain.
The rst property, the non-bypassable property, implies an additional layer of indirection before the page table that all memory requests must pass through.
The second property, the guarded manipulation property, requires that segment descriptors be distinguished from general purpose data by the processor hardware, not only in registers, but also in memory. This segment manipulation property also implies new instructions for manipulating segment descriptors, or at least special restrictions on general purpose instructions when manipulating segment descriptors.
The third property, the protected call gate property, suggests a special ow control instruction with the ability to safely leave a domain, as de ned by a set of segments, and enter a new domain. 3.1
We have chosen to implement our RISC capability model by extending the 64-bit MIPS instructions set. We selected MIPS because it has a well established 64-bit instruction set and adheres to a prototypical RISC philosophy.
We chose to implement the universal enforcement property by adding a segment table through which all virtual addresses are o set before reaching the page table. General purpose loads and stores are implicitly o set via a xed segment in the table and instruction fetches are o set via another xed segment. This xed implicit o set model is very similar to the i286 segment model. We have also added a complete complement of new load and store instructions which allow explicit use of other segments in the table.
By storing segment descriptors in a distinct register le, separate from general purpose registers, we partially ful ll the guarded manipulation property by not allowing general purpose manipulation. We also added a dedicated set of segment descriptor manipulation instructions which only allow reducing the privilege of descriptors. We decided to protect segment descriptors in memory using tags on general purpose memory locations rather than using dedicated memory so that compilers could treat descriptors as they do pointers, including storing them on the stack and passing them as arguments.
We are able to ful ll the protected call gate property with a single-cycle instruction. We observe that a domain can be trusted to manually store its own state and to \unpack" its own state when it is called. Since any number of segment descriptors can be stored in a segment, it is only necessary to make a single segment available in a new domain for the entire domain to be \unsealed". To facilitate this, we allow segments to be sealed by a domain and passed to other domains to be used in protected calls. This simple primitive is su cient to support protected procedure calls and is easily implemented as a standard single cycle instruction.
Possibly the most radical feature mentioned above is tagged memory, which implies an extra bit for each word in memory. We were able to implement this with a simple scheme which is practical in a traditional computer system without modifying the external memory hierarchy. The tags for DRAM locations are stored together in the top of DRAM and a small tag controller sits at the mouth of the memory controller on the processor and provides a tag for every memory request made by the core. Our segment descriptors are 256 bits wide and must be aligned in memory, thus we have an overhead of 1-bit for every 256-bits of data (i.e. 0.4%). 4
We have only begun to evaluate our segment implementation, but we hope to demonstrate that several key applications will bene t from our RISC capability segment model. 4.1
We would like to thoroughly study the low-level performance of crossing between protection domains using our novel RISC style protected procedure calls. This will include various trust relationships: mutually untrusting domains and calls with asymmetric trust. Our methodology here will likely focus on performance and compare against x86 segmentation domain crossings as well as domain crossings using seperate address spaces. 4.2
We would like to demonstrate that our capability segment model can conveniently and e ciently support application sandboxing. State of the art application sandboxing depends on process separation using TLB enforcement. Thus protected interactions which are logically procedure calls must be implemented as inter-process communication involving the operating system and two independent memory spaces. Allowing program components to run in a hardware enforced segment of the program's address space should allow a simpler communication model and more e cient use of the TLB.
We have experience with the Capsicum [
Segments in our model can be used as general purpose pointers with a limited range of modi cations available. David Chisnall has extended Clang and LLVM to accept annotations that implement pointers as segments to ensure they are used according to programmer intent, including bounds checking and read, write, and execute property enforcement. This approach is designed to allow simple security enhancement of existing code bases in C which often have poor security properties. We plan to evaluate usability of the annotations by measuring the number of lines that needed modi cation for added security bene t compared to pervasive bounds checking, and by attempting to compare the clarity of resulting code. 5
Modern ELF les which are consumed by a linker to incorporate binaries into a running program specify segments of the program along with properties for each segment. It should be possible to build a custom linker which constructs a segment descriptor for each ELF segment and implements memory references as segment loads and stores.
Flexible segment hardware should allow managed language runtimes to be simpler, faster, and more secure. A straight forward use of segment registers as pointers and of protected calls on invocations would provide strong hardware protection of managed language objects.
6
Static analysis of computer programs for correctness has proven very promising. If segment manipulation was part of the user space code stream, static analysis may be able to make a breakthrough in reducing proof complexity. We hope to demonstrate that a user space segment model is useful in the context of the modern software stack to enhance the security and correctness of computer programs. We also hope to demonstrate that a user space capability segment model is implementable in a modern RISC processor without breaking the principles of RISC design.
An FPGA implementation of the 64-bit MIPS processor will be available for download this year and we will welcome collaboration with researchers who would like to apply our capability segment model to their own challenges in engineering secure software and systems. 6.1
We would like to thank our colleagues - especially Peter Neumann, Jonathan Anderson, Ross Anderson, Nirav Dave, Ben Laurie, Steven J. Murdoch, Philip Paeps, Michael Roe, David Chisnall, Robert Norton and Khilan Gudka.
This PhD work is part of the CTSRD Project which is sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contract FA8750-10-C-0237. The views, opinions, and/or ndings contained in this report are those of the authors and should not be interpreted as representing the o cial views or policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the Department of Defense.