Efficient Softwarebased Fault Isolation

1
Efficient Software-based Fault Isolation

• Robert Wahbe, Steven Lucco,
• Thomas E. Anderson Susan L. Graham
• Presented By
• Ali Bakhoda
• Fall 2006

2
Motivation

• Faults in extension modules make applications
  unreliable
• We want to protect modules boundaries and still
  allow cooperation
• Hardware boundaries provide automatic protection
  (Hardware protectionseparate address spacesRPC
  )
• Crossing hardware boundaries is very expensive

3
Motivation

• So hardware protection is expensive
• Perhaps software protection mechanism could
  provide better performance.
• When?
• Significant portion of time being spent in
  operating system context switch code
• Only a small amount of code is distrusted

4
The Big Picture

• Only protect distrusted code
• Distrusted code cannot mess with trusted code
• Distrusted code slows down
• RPC improves
• Overall performance increase

5
Software-Enforced Fault Isolation
Code
Data
Code
Data
Single Address Space
Task A
Task B

• Related processes run together in one address
  space
• Divide the address space into segments
• Each task gets its own fault domain
• Code Segment
• Data Segment
• Contiguous and isolated from other tasks
• Software checks to make sure code doesnt violate
  protection domain boundaries
• Can only jump to addresses within its code
  segment
• Can only write to addresses within its data
  segment

6
Segment Matching
Target Address
Segment ID
Upper Address Bits

• Compiler inserts code before each unsafe
  instruction to make sure task stays within
  boundaries of fault domain
• Unsafe means not statically verifiable
• Jumps through registers
• Stores that use a register as a target address
• Inserted code verifies that jump and store
  destination upper address bits match constant
  offset (segment identifier)
• 4 extra instructions
• Uses 4 dedicated registers accessed only by
  inserted code
• Is it in the correct segment?
• If not, trap to system error routine outside
  fault domain
• Can pinpoint the offending instruction
• Used to verify code during development

7
Sandboxing Runtime Method
Target Address
Segment ID
overwrite

• Reduce fault isolation overhead through a simpler
  mechanism
• Compiler inserts code to simply overwrite upper
  address bits with segment Identifier
• Ensures all accesses stay within boundaries
• Does not identify source of fault
• Requires only 2 instructions
• Requires 5 dedicated registers instead of 4
• Verifiable

8
Process Resources

• Distrusted code can still corrupt other tasks by
  acting on resources allocated at address-space
  level (close/delete files, etc.)
• Solution Distrusted code cannot make system
  calls directly
• but must use RPC-like semantics
• Central, trusted arbitration code handles system
  calls on behalf of distrusted code
• Unsafe operations are disallowed
• Trusted code shares a fault domain with the
  arbitration code an can make system calls directly

9
Data Sharing

• Read sharing is free as reads are not sandboxed
• Write sharing provided by lazy pointer swizzling
• Modify page table to map shared region at same
  offset within each fault domain that needs access
• Low order address bits remain the same
• Upper address bits are the segment ID of each
  protection domain

10
Fault Domain RPC

• Jump table written in code segment by trusted
  module
• Hand-generated stubs for each pair of fault
  domains
• Stubs are trusted by callee so they can copy
  arguments directly to callee data segment
• Stubs also manage machine state push pop
  registers like function calls skip those that
  arent changed
• RPC resistant to fatal errors (addressing
  violation, etc.)
• Faults in callee are returned to caller
• Infinite loops are interruptedby timers in
  trusted code if they take too long

11
Performance

• Software fault isolation cheaper than RPCs when
  at least 5 of CPU time is spent in domain
  crossings
• Much cheaper than traditional context switches
• For frequent RPCs, cheaper than theoretical
  minimum hardware boundary crossing (LRPC)

12
Summary

• Software fault isolation uses two mechanisms to
  enforce process boundaries
• Constrain jumps and writes to addresses within
  fault domain
• Restrict accesses to system calls by non-trusted
  code
• Shared address space means RPCs become simple
  jump instructions
• Extra instructions and dedicated registers
  increase runtime relative to unprotected function
  calls but result in net performance win if at
  least 5 of CPU time would be spent crossing
  address boundaries

13
Discussion