Application compartmentalization Conventional gunzip - - PowerPoint PPT Presentation

application compartmentalization
SMART_READER_LITE
LIVE PREVIEW

Application compartmentalization Conventional gunzip - - PowerPoint PPT Presentation

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


slide-1
SLIDE 1

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.

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

slide-2
SLIDE 2

Application compartmentalization

Application compartmentalization mitigates vulnerabilities by decomposing applications into isolated compartments delegated limited rights

2

UNIX process Kernel main loop vulnerable decompression code Kernel UNIX process Capability-mode process main loop vulnerable decompression code Compartmentalized gunzip Conventional gunzip

slide-3
SLIDE 3

Compartmentalization vision

3

slide-4
SLIDE 4

4

HTTP GET sandbox

  • 5. fetch

URL-specific sandbox URL-specific sandbox SSL sandbox HTTPS sandbox network sandbox Code-centred compartmentalisation Data-centered compartmentalisation

  • 1. fetch

main loop http ssl ftp URL-specific sandbox main loop http ssl ftp FTP sandbox

  • 2. fetch

main loop http ssl ftp HTTP sandbox

  • 3. fetch

main loop http ssl FTP sandbox ftp SSL sandbox HTTP auth sandbox

  • 4. fetch

main loop http auth ssl FTP sandbox ftp http get

  • A single application has many possible

compartmentalizations

  • Each trade off security against performance

and programming complexity

  • But the process model is problematic:
  • Limited simultaneous-process scalability
  • Multi-address-space programming model
slide-5
SLIDE 5

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

  • Inefficient and hard-to-program

foundation for granular software compartmentalization

5

Process1 Process2 Physical memory

slide-6
SLIDE 6

6

If you could revise the fundamental principles of computer system design to improve security… …what would you change?

slide-7
SLIDE 7

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

slide-8
SLIDE 8

CHERI MEMORY PROTECTION

8

slide-9
SLIDE 9

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

slide-10
SLIDE 10

Virtual memory vs. capabilities

10

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, shootdowns Per-pointer overhead, 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!

slide-11
SLIDE 11

permissions (31 bits) length (64 bits)

  • ffset (64 bits)

base (64 bits)

CHERI capabilities

  • Capabilities are fat pointers with strong integrity properties
  • Guarded manipulation enforced monotonic rights decrease
  • Tags protection integrity; can’t dereference invalid capability
  • Tagged memory maintains integrity in RAM

11

256-bit capability

Virtual address space

v 1-bit tag

slide-12
SLIDE 12

Instruction Fetch Register Fetch Decode Execute Writeback Capability Coprocessor Instruction Cache MMU: TLB Data Cache Memory Memory Access L2 Cache Tag Controller

Capability extensions to pipeline

  • 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

slide-13
SLIDE 13

13

OS kernel

Address-space executive Address-space executive

Legacy application + capability libraries

Address-space executive

Pure-capability application

Virtual address spaces

Hybrid capability/MMU OSes

Capability-based OS with legacy libraries CHERI CPU libssl

zlib

zlib

zlib

zlib class1 libssl class2

libssl

libssl

Single address space

Our focus: hybridizing conventional virtual-memory security and in-address- space capability systems Single-address-space systems are also possible on CHERI

slide-14
SLIDE 14

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

slide-15
SLIDE 15

Binary compatibility

  • 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

More compatible Safer N64 Pure MIPS Hybrid Some pointers are capabilities Pure-capability All pointers are capabilities

slide-16
SLIDE 16

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

slide-17
SLIDE 17

CHERI COMPARTMENTALIZATION

17

slide-18
SLIDE 18

CheriBSD object capabilities

  • In-process object-capability model
  • Per-thread capability register file

describes its protection domain

  • Domain transition within threads

via register-file transformation

  • Object capabilities support strong

encapsulation, mutual distrust

  • libcheri implements classes, objects
  • CCall/CReturn exception

handlers unseal capabilities

  • Capabilities passed via call, return
  • Trusted stack provides reliable

software-defined return, recovery

18

Virtual address space … $c0 $c1 $c2 $c31 $c3 … $c0 $c1 $c2 $c31 $c3 Thread1 capability registers Thread2 capability registers

slide-19
SLIDE 19

permissions (31 bits)

  • bjtype (24bits)

s length (64 bits)

  • ffset (64 bits)

base (64 bits)

Supporting object capabilities

  • 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

256-bit capability

slide-20
SLIDE 20

Object-capability call/return

Compartmentalized object Ambient object Compartmentalized object Ambient object Kernel CCall CCall System call CReturn CReturn System- call return CReturn CCall

  • Initial registers after execve()

grant ambient authority

  • Synchronous function-like call

fits current application/library programming styles

  • CCall/CReturn ABI clears

unused registers to prevent data or capability leakage

  • Only authorized system

classes can make system calls

  • Constant overhead to

function-call cost

20

slide-21
SLIDE 21

Application implications

Pros

  • Single address-space

programming model

  • Referential integrity matches

programmer model

  • Only modest work to insert

protection-domain boundaries

  • Objects permit mutual distrust
  • Constant (low) overhead

relative to function calls even with large memory flows

Cons

  • Still have to reason about the

security properties

  • Shared memory is more subtle

than copy semantics

  • Capability overhead in data

cache is real and measurable

  • ABI subtleties between MIPS

and CHERI compiled code

  • Lower overhead raises further

cache side-channel concerns

21

slide-22
SLIDE 22

CHERI COMPARTMENTALIZATION PERFORMANCE

22

slide-23
SLIDE 23

CHERI hardware/software prototypes

  • Bluespec FPGA prototype
  • 64-bit MIPS + CHERI ISA
  • Pipelined, L1/L2 caches, MMU
  • Synthesizes at ~100MHz
  • Realistic (modest) illustration of what

could be accomplished in silicon designs

  • Capability-aware software
  • CheriBSD OS
  • CHERI clang/LLVM compiler
  • Adapted applications
  • Open-source release

23

Implementation on FPGA

Instruction Fetch Register Fetch Decode Execute Writeback Capability Coprocessor Instruction Cache MMU: TLB Data Cache Memory Memory Access L2 Cache Tag Controller

slide-24
SLIDE 24

24

Updated ISCA/ASPLOS results looking at the cache- footprint question? Include 128-bit simulation

slide-25
SLIDE 25

25

Domain-switching overhead

slide-26
SLIDE 26

Library compartmentalization

26

slide-27
SLIDE 27

ONGOING REFINEMENT TO THE CHERI MODEL

27

slide-28
SLIDE 28

Hardware and software refinement

  • Architecture performance / cost
  • Re-converge register files
  • 128-bit compressed capabilities
  • Explore and evaluate application to a non-MIPS ISAs
  • Software model and compatibility
  • Compiler and ABI refinement
  • Software compartmentalization models
  • Hybrid system call layer
  • Complete capability-ABI FreeBSD version
  • Reliable and accurate garbage collection

28

slide-29
SLIDE 29

Capability compression

  • Exchange precision for reduced register size, cache footprint
  • Floating-point style representation
  • Unlike prior schemes, support pointer “out of bounds” for C
  • Important: retain monotonicity for safe delegation!
  • Great care must be taken with security—performance trade offs

29

128-bit capability

Virtual address space

v 1-bit tag

perms (23 bits)

exp (6)

s toTop toBase f

pointer (64 bits)

mask = 0xffffffffffffffff << exp top = (pointer + (toTop << exp)) & mask base = (pointer + (toBase << exp)) & mask

slide-30
SLIDE 30

Papers and reports

CHERI: A Hybrid Capability-System Architecture for Scalable Software

  • Compartmentalization. Robert N. M. Watson, Jonathan Woodruff, Peter G. Neumann,

Simon W. Moore, Jonathan Anderson, David Chisnall, Nirav Dave, Brooks Davis, Khilan Gudka, Ben Laurie, Steven J. Murdoch, Robert Norton, Michael Roe, Stacey Son, and Munraj

  • Vadera. IEEE Security and Privacy 2015.

Beyond the PDP-11: Processor support for a memory-safe C abstract machine. David Chisnall, Colin Rothwell, Brooks Davis, Robert N.M. Watson, Jonathan Woodruff, Simon W. Moore, Peter G. Neumann and Michael Roe. ASPLOS 2015. The CHERI capability model: Revisiting RISC in an age of risk. Jonathan Woodruff, Robert N. M. Watson, David Chisnall, Simon W. Moore, Jonathan Anderson, Brooks Davis, Ben Laurie, Peter G. Neumann, Robert Norton, and Michael Roe. ISCA 2014. Capability Hardware Enhanced 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, and Michael Roe. UCAM-CL-TR-864, Cambridge, December 2014.

30

slide-31
SLIDE 31

Conclusions

  • Hybrid capability model for fine-grained, in-address-space

memory protection

  • Supplements current MMU
  • Targets C-language TCBs
  • Object-capability model for granular, in-address-space

compartmentalization

  • Software-defined domain-transition model
  • Reference-oriented programmer model restored
  • Efficient non-IPC communication with protection
  • Open-source reference implementation, ISA specification:

http://www.cheri-cpu.org/

31

slide-32
SLIDE 32

Q&A

32

slide-33
SLIDE 33

BACKUP SLIDES

33

slide-34
SLIDE 34

Domain-switch pseudocode

CCall CReturn

34

TODO

slide-35
SLIDE 35

CCall - cycle-by-cycle analysis

(Including user and kernel space)

35

Module Phase #instr. #cycles Caller Setup call, clear unused argument registers 22 * 42 * libcheri Save callee-save regs, push call frame 30 ** 34 ** Kernel Receive trap 13 28 Validate CCall args 79 * ** 79 * ** Push trusted stack, unseal Ccall args. 31 41 ** Clear non-argument registers 4 4 Exit kernel 7 12 Sandbox Set up sandbox 33 59 219 299

* Further opportunities for hardware optimization ** Will further reduce with smaller registers, converged register file

slide-36
SLIDE 36

CReturn cycle-by-cycle analysis

(Including user and kernel space)

36

Module Phase #instr. #cycles Sandbox Exit sandbox 12 16 Kernel Receive trap 13 31 Validate return capability 7 7 Pop trusted stack 26 41 Clear non-return registers 4 4 Exit kernel 7 7 libcheri Pop call frame, restore regs. 28 52 Caller Back in caller 1 1 99 159

* Further opportunities for hardware optimization ** Will further reduce with smaller registers, converged register file

slide-37
SLIDE 37

37

slide-38
SLIDE 38

38