Presentation is loading. Please wait.

Presentation is loading. Please wait.

Efficient Software-based Fault Isolation Robert Wahbe, Steven Lucco, Thomas E. Anderson & Susan L. Graham Presented By Tony Bock.

Similar presentations


Presentation on theme: "Efficient Software-based Fault Isolation Robert Wahbe, Steven Lucco, Thomas E. Anderson & Susan L. Graham Presented By Tony Bock."— Presentation transcript:

1 Efficient Software-based Fault Isolation Robert Wahbe, Steven Lucco, Thomas E. Anderson & Susan L. Graham Presented By Tony Bock

2 Motivation Developers desire the protect individual processes through system of boundaries but still allow cooperation Developers desire the protect individual processes through system of boundaries but still allow cooperation Hardware boundaries provide automatic protectionHardware boundaries provide automatic protection Crossing hardware boundaries is very expensiveCrossing hardware boundaries is very expensive Perhaps software protection mechanism could provide better performance? Perhaps software protection mechanism could provide better performance?

3 Sandboxing Related processes run together in one address space Related processes run together in one address space Each task gets it’s own fault domain Each task gets it’s own fault domain Code SegmentCode Segment Data SegmentData Segment Contiguous and isolated from other tasksContiguous and isolated from other tasks Software checks to make sure code doesn’t violate protection domain boundaries Software checks to make sure code doesn’t violate protection domain boundaries Can only jump to addresses within it’s code segmentCan only jump to addresses within it’s code segment Can only write to addresses within it’s data segmentCan only write to addresses within it’s data segment CodeDataCodeData Task ATask B Single Address Space

4 Sandboxing: Segment Matching Compiler inserts code before each unsafe instruction to make sure task stays within boundaries of fault domain Compiler inserts code before each unsafe instruction to make sure task stays within boundaries of fault domain Unsafe instructions include: Unsafe instructions include: Jumps through registersJumps through registers Stores that use a register as a target addressStores that use a register as a target address Inserted code verifies that jump and store destination upper address bits match constant offset (segment identifier) Inserted code verifies that jump and store destination upper address bits match constant offset (segment identifier) Typically four instructionsTypically four instructions Uses four dedicated registers accessed only by inserted code: segment ID, segment shift, code address, data addressUses four dedicated registers accessed only by inserted code: segment ID, segment shift, code address, data address Used to statically verify code during development Used to statically verify code during development Segment ID Target Address = Upper Address Bits

5 Sandboxing: Runtime Method Reduce fault isolation overhead through a simpler mechanism Reduce fault isolation overhead through a simpler mechanism Compiler inserts code to simply overwrite upper address bits with segment ID Compiler inserts code to simply overwrite upper address bits with segment ID Ensures all accesses stay within boundariesEnsures all accesses stay within boundaries Does not identify source of faultDoes not identify source of fault Requires only two instructions Requires only two instructions Five dedicated registers: segment mask, code & data segment IDs, code & data addresses Five dedicated registers: segment mask, code & data segment IDs, code & data addresses Segment ID Target Address overwrite

6 Resource Sharing Assuming no fault domain violations, non-trusted code can still corrupt other tasks by acting on resources allocated at address-space level (open files, etc.) Assuming no fault domain violations, non-trusted code can still corrupt other tasks by acting on resources allocated at address-space level (open files, etc.) Solution: Non-trusted code cannot make system calls directly but must use RPC-like semantics Solution: Non-trusted code cannot make system calls directly but must use RPC-like semantics Central, trusted arbitration code handles system calls on behalf of non-trusted codeCentral, trusted arbitration code handles system calls on behalf of non-trusted code Unsafe operations are disallowedUnsafe operations are disallowed Trusted code shares a fault domain with the arbitration code an can make system calls directlyTrusted code shares a fault domain with the arbitration code an can make system calls directly CodeDataCodeData Task ATask B CodeData Trusted Code

7 Data Sharing Read sharing is free as reads are not sandboxed Read sharing is free as reads are not sandboxed Write sharing provided by lazy pointer swizzling Write sharing provided by lazy pointer swizzling Modify page table to map shared region at same offset within each fault domain Modify page table to map shared region at same offset within each fault domain Low order address bits remain the sameLow order address bits remain the same Upper address bits are the segment ID of each protection domainUpper address bits are the segment ID of each protection domain Code Task ATask B Data

8 Fault Domain RPC Jump table written in code segment by trusted module Jump table written in code segment by trusted module Hand-generated stubs call into jump table which transfers control to callee fault domain Hand-generated stubs call into jump table which transfers control to callee fault domain Stubs are trusted by callee so they can copy arguments directly to callee data segmentStubs 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 aren’t changedStubs also manage machine state: push & pop registers like function calls – skip those that aren’t changed RPC resistant to fatal errors RPC resistant to fatal errors Faults in callee are returned to callerFaults in callee are returned to caller Infinite loops are interrupted by timerInfinite loops are interrupted by timer

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

10 Summary Software fault isolation uses two mechanisms to enforce process boundaries Software fault isolation uses two mechanisms to enforce process boundaries Constrain jumps and writes to addresses within fault domainConstrain jumps and writes to addresses within fault domain Restrict accesses to system calls by non-trusted codeRestrict accesses to system calls by non-trusted code Shared address space means RPCs become simple jump instructions 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 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


Download ppt "Efficient Software-based Fault Isolation Robert Wahbe, Steven Lucco, Thomas E. Anderson & Susan L. Graham Presented By Tony Bock."

Similar presentations


Ads by Google