CHERI A Hybrid Capability-System Architecture for Fine-grained Memory Protection and Compartmentalization Robert N.M. Watson, Peter G. Neumann, Jonathan Woodruff, Simon W. Moore, Jonathan Anderson, Ruslan Bukin, David Chisnall, Nirav Dave, Brooks Davis, Khilan Gudka, Alexandre Joannou, Chris Kitching, Ben Laurie, A. Theo Markettos, Alan Mujumdar, Steven J. Murdoch, Robert Norton, Michael Roe, Colin Rothwell, Stacey Son, Munraj Vadera, and Bjoern Zeeb University of Cambridge, SRI International May 2015 Approved for public release; distribution is unlimited. This research is sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (‘CTSRD’) and FA8750-11-C-0249 (‘MRC2’). The views, opinions, and/or findings contained in this article/presentation are those of the author(s)/presenter(s) and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.
Application compartmentalization Conventional gunzip Compartmentalized gunzip UNIX process UNIX process Capability-mode process main loop vulnerable decompression main loop vulnerable code decompression code Kernel Kernel Application compartmentalization mitigates vulnerabilities by decomposing applications into isolated compartments delegated limited rights 2
Compartmentalization vision 3
Code-centred compartmentalisation 1 . fetch 2 . fetch 3 . fetch 4 . fetch main loop main loop main loop main loop ftp http ftp http ftp http ftp http auth http get Data-centered compartmentalisation FTP FTP HTTP FTP HTTP auth HTTP GET sandbox sandbox sandbox sandbox sandbox sandbox ssl ssl network sandbox HTTPS SSL ssl ssl sandbox sandbox SSL sandbox 5 . fetch main loop • A single application has many possible ftp http compartmentalizations ssl URL-specific sandbox • Each trade off security against performance URL-specific sandbox URL-specific sandbox and programming complexity • But the process model is problematic: • Limited simultaneous-process scalability • Multi-address-space programming model 4
The process-model consensus Coarse-grained process isolation • • Inter-program robustness • Multi-user access control Memory Management Unit (MMU) • • Page tables control per-process virtual-to-physical mappings • Translation Look-aside Buffer (TLB) Bridged via Inter-Process Communication (IPC) • and other kernel services (e.g., filesystem) Inefficient and inadequate foundation for • granular memory protection Process 1 Process 2 Inefficient and hard-to-program • Physical foundation for granular software memory compartmentalization 5
If you could revise the fundamental principles of computer system design to improve security… …what would you change? 6
CHERI capability model ISCA 2014 : Fine-grained, in-address-space memory protection • • Capabilities replace pointers for data references • Data-pointer integrity , control-flow integrity , bounds checking • Hybrid model lives side-by-side with a conventional MMU ASPLOS 2015 : Explore and refine C-language compatibility • • Converge fat-pointer and capability models • Develop binary-compatibility models Oakland 2015 : Software compartmentalization with CHERI • • Object-capability model implemented over hardware capabilities • Efficient, in-address-space software-defined domain transition 7
CHERI MEMORY PROTECTION 8
Revisiting RISC in an age of risk • Fine-grained, capability-based in-address-space protection • Deconflate virtualization and protection – retain MMU • Implement spatial protection (e.g., bounds checking) • Foundation for temporal protection (e.g., GC) • Foundation for fine-grained compartmentalization • A RISC approach • Instructions are for compilers • Unprivileged fast paths, software slow paths • Prototype on 64-bit MIPS, but more broadly applicable 9
Virtual memory vs. capabilities Virtual Memory Capabilities Protects Virtual addresses and pages References (pointers) to C code, data structures Hardware MMU, TLB Capability registers, tagged memory Costs TLB, page tables, lookups, Per-pointer overhead, shootdowns context switching Compartment scalability Tens to hundreds Thousands or more Domain crossing IPC Function calls Optimization goals Isolation, full virtualization Memory sharing, frequent domain transitions CHERI hybridizes these models: pick two! 10
CHERI capabilities 1-bit tag v permissions (31 bits) 256-bit capability length (64 bits) offset (64 bits) base (64 bits) • Capabilities are fat pointers with strong integrity properties • Guarded manipulation enforced monotonic rights decrease Virtual • Tags protection integrity; can’t dereference invalid capability address space • Tagged memory maintains integrity in RAM 11
Capability extensions to pipeline Instruction Register Memory Decode Execute Writeback Fetch Fetch Access Capability Coprocessor Instruction Cache MMU: TLB Data Cache L2 Cache Tag Controller Memory • Capability coprocessor provides capability registers, instructions • Interposes on legacy MIPS load/store instructions, instruction fetch • Processing ‘before’ MMU makes capabilities address-space relative • Tag controller associates tags with in-memory capabilities • Under the hood: memory partitioned, with a region holding all tags 12
Hybrid capability/MMU OSes Virtual address spaces zlib zlib libssl zlib libssl zlib libssl class1 Single address space libssl Legacy application class2 Pure-capability + application capability libraries Capability-based OS with legacy Address-space executive Address-space executive libraries OS kernel Address-space executive CHERI CPU Single-address-space Our focus: hybridizing conventional systems are also virtual-memory security and in-address- possible on CHERI space capability systems 13
C-language memory protection • Compiler implements C pointers in terms of capabilities • Strong pointer integrity and use limits • Tag detects any pointer corruption • Bounds checking, with subsetting • Permissions constrain use (e.g., read-only, W^X) • Protects data and control flow integrity • Out-of-bounds data access eliminated • Data-pointer confusion eliminated • Support for accurate garbage collection 14
Binary compatibility More compatible Safer N64 Hybrid Pure-capability Pure MIPS Some pointers All pointers are are capabilities capabilities • MIPS code lives side-by-side with CHERI code • Incremental adoption options – e.g., shifting to capabilities for return addresses, just stack pointers, etc. 15
CHERI OS considerations Prototyped using the FreeBSD operating system (+/- 4 KLoC) • • Changes for user memory protection, compartmentalization Process model extended for tagged capabilities • • Register-file setup and maintenance (exec, switch, thread create) • Virtual-memory support for physical tags • Signal-handling, debugging extensions Fine-grained, in-address-space object-capability security model • • Kernel CCall/CReturn exception handlers • System calls blocked from non-system classes • Userspace compartmentalization runtime 16
CHERI COMPARTMENTALIZATION 17
CheriBSD object capabilities • In-process o bject-capability model • Per-thread capability register file describes its protection domain $c0 $c1 • Domain transition within threads $c2 via register-file transformation $c3 $c0 $c1 • Object capabilities support strong … encapsulation , mutual distrust $c2 $c3 • libcheri implements classes , objects $c31 … Thread 1 • CCall / CReturn exception capability handlers unseal capabilities registers $c31 • Capabilities passed via call, return Thread 2 capability • Trusted stack provides reliable registers Virtual software-defined return, recovery address 18 space
Supporting object capabilities objtype (24bits) permissions (31 bits) s 256-bit capability length (64 bits) offset (64 bits) base (64 bits) • Sealed bit prevents modification, dereferencing: encapsulation • Object types atomically link code , data pairs to create objects • Object invocation mechanism unseals capability pairs • Userspace TCB manages object-type namespace 19
Object-capability call/return • Initial registers after execve() grant ambient authority Ambient object CCall CReturn • Synchronous function-like call fits current application/library Compartmentalized object programming styles CCall CReturn • CCall/CReturn ABI clears Compartmentalized object unused registers to prevent CCall CReturn data or capability leakage Ambient object • Only authorized system classes can make system calls System System- call call return Kernel • Constant overhead to function-call cost 20
Application implications Pros Cons • Single address-space • Still have to reason about the programming model security properties • Referential integrity matches • Shared memory is more subtle programmer model than copy semantics • Only modest work to insert • Capability overhead in data protection-domain boundaries cache is real and measurable • Objects permit mutual distrust • ABI subtleties between MIPS and CHERI compiled code • Constant (low) overhead relative to function calls even • Lower overhead raises further with large memory flows cache side-channel concerns 21
CHERI COMPARTMENTALIZATION PERFORMANCE 22
Recommend
More recommend
