Efficient Software-Based Fault Isolation

1. Efficient Software-Based Fault Isolation By: Robert Wahbe Steven Lucco Thomas E. Anderson Susan L. Graham

2. Overview • Background • Software Fault Isolation • Efficient software encapsulation • Fast communication across fault domains • Performance Analysis

3. Background • Application extensibility requirements • Micro-kernel design • Examples • Quark Xpress desktop publishing system – third party software to extend the system • Epoch’s tertiary storage file system – kernel code developed by third part

4. Background • Problem -- Trust • Example: • Quark Xpress: extension modules can corrupt Quark’s internal data structures • Solutions: Fault Isolation • Using RPC in separate address spaces • Software fault isolation within a single address space

5. Why choose software fault isolation • Hardware fault isolation Cost • A significant portion of the overall execution time doing context switch instead of executing code • Distrusted/trusted code • Only a small amount of the code is distrusted • Most of the execution time is spent in trusted code.

6. Software Fault Isolation • Virtual address segments • Each segment share a unique upper bits (segment identifier) • Distrusted module can jump to or write to the same upper bit pattern (segment identifier) • Software encapsulation techniques • Segment Matching • Address Sandboxing

7. Segment Matching • Insert checking code before every unsafe instruction • Checking code determines whether the unsafe instruction has the correct segment identifier • Trap to a system error routine if checking fails – pinpoint the offending instruction

8. Segment Matching pseudo code

9. Address Sandboxing • Reduce runtime overhead further compared to segment matching by not pinpointing the offending instruction • Before each unsafe instruction, inserting codes can set the upper bits of the target address to the correct segment identifier

10. Address Sandboxing pseudo code

11. Reduce the overhead by avoiding arithmetic that computes target addresses Sandboxing only the register reg Guard zones needed – virtual memory pages adjacent to the segment are unmapped Sandboxing Optimization

12. Process Resources • Fault domains share same virtual address space – need to prevent distrusted modules from corrupting resources • Require distrusted modules to access systems resources thru cross-fault-domain RPC only • If a distrusted module performs a direct system call, transform this call into the appropriate RPC call

13. Read-only sharing is allowed Fault domain can store to its only segment Fault domains can read any memory from the application’s address space Read-write sharing using lazy pointer swizzling -- aliased Lazy pointer swizzling Data sharing Sourced from Carl Yao

14. only way to escape a fault domain is via a jump table Legal entry point outside the domain in jump table Table is read-only, can only be modified by trusted module Cross Fault Domain Communication

15. Comparison with other message passing techniques

16. Performance Results • Encapsulation overhead • Fault Domain Crossing

17. Tradeoffs relative to RPC/LRPC: - better crossing (an order of magnitude better than LRPC) - need slightly more execution time 4.3% in distrusted module - shaded area means cross fault domain is a better choice - if an application spends 10% of the its time crossing fault domain, requires a 39% improvement in crossing time: 1.10 micros relative to 1.80 micros for other RPC/LRPC – does not have such machine Performance Analysis