190 likes | 224 Views
Efficient Software-Based Fault Isolation. By: Robert Wahbe Steven Lucco Thomas E. Anderson Susan L. Graham. Overview. Background Software Fault Isolation Efficient software encapsulation Fast communication across fault domains Performance Analysis. Background.
E N D
Efficient Software-Based Fault Isolation By: Robert Wahbe Steven Lucco Thomas E. Anderson Susan L. Graham
Overview • Background • Software Fault Isolation • Efficient software encapsulation • Fast communication across fault domains • Performance Analysis
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
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
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.
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
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
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
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
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
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
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
Performance Results • Encapsulation overhead • Fault Domain Crossing
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