Efficient Software Based Fault Isolation

1. Efficient Software Based Fault Isolation Author: Robert Wahobe,Steven Lucco,Thomas E Anderson, Susan L Graham Presenter: Maitree kanungo Date:02/17/2010

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

3. Why Software fault isolation: • Hardware-based Fault Isolation • Run modules in separate address spaces • Communicate via Remote Procedure Call • Switch to kernel mode • Copy arguments • Save/Restore registers • Switch address spaces • Return to user mode • Context switches are expensive

4. Software Fault Isolation Virtual address segments • Each segment share a unique upper bits called segment identifier • Distrusted module can jump to or write to the same upper bit pattern (segment identifier)

5. Techniques of Fault Isolation 2techniques for software based fault-isolation. • Segment matching • Sandboxing

6. Techniques of Fault Isolation • This technique involves modifying the software binary to prevent stores or jumps from leaving a certain range of addresses. • All addresses used in store or jump locations are either checked or modified to enforce this. • Straight modification without checking (i.e., by bit substitution) is "sandboxing", • checking and error reporting is "segment matching"

7. Fault Domain 990--- 991--- 991--- 992--- 992--- 993--- … … … Segment (code) Segment (data) Each segment has unique pattern of upper bits called“ segment identifier” Fault Domain

8. What is Segment Matching • Static verification: Target address is known at compiling time • Unsafe instruction: Jumps & stores instruction which cannot be statically verified to be correct segment until at runtime. It could corrupt permanent data. • Segment matching • Insert checking code before every unsafe instruction. The checking code determines whether the unsafe instruction’s target address has the correct segment identifier.

9. Example of segment matching • Say an unsafe instruction is located in segment 101, but wants to write to segment 100. Initially, target address=10001111; • segment-reg=101; shift-reg=5 (or 101); dedicated-reg = 10001111 dedicated-reg>>shift-reg = 100, so scratch-reg = 100 segment-reg=101; scratch-reg=100; not equal! A trap is generated to trigger a system error routine outside the distrusted module’s fault domain. If they match, then we know the target address is indeed inside the same segment, so we can run: store value, dedicated-reg

10. Segment Matching • Requires 4 dedicated registers to hold: • address in data segment • address in code segment • segment shift amount • segment identifier

11. Address Sandboxing • Segment matching can pinpoint the offending instruction. • Sandboxing reduces runtime overhead further, at the cost of providing no info about the source of faults. • Before each unsafe instruction we simply insert code that sets the upper bits of the target address to the correct segment ID.

12. Pseudo code for Address Sandboxing Again say an unsafe instruction is located in segment 101, but wants to write to segment 100. Initially, target-reg=10001111; segment-reg=101; and-mask-reg=00011111; target-reg&and-mask-reg = 00001111 so dedicated-reg=00001111 segment-reg | dedicated-reg = 10101111. so dedicated-reg = 10101111. store value, dedicated-reg Now instead of writing to the intended unsafe location 10001111, sandboxing changed the target address to 10101111, which is in the same fault domain of the writing instruction. In this case may be this fault domain will be corrupt, but it does not affect other fault domains. .

13. Guard Zone Optimization • RISC architectures include a register-plus-offset instruction mode. • Take instruction “store value, offset(reg)”. • To avoid calculating reg+offset, • we directly sandbox the reg, at the expense of creating guard zones at the top and bottom of each segment. • Avoid sandboxing the use of stack pointer by sandboxing the dedicated register which significantly improves performance.

14. Cross Fault Domain Communication • Control escapes a distrusted fault domain only via a jump table (to stub instruction). • A call-stub and a return-stub are created for each pair of fault domains. • The stub is also responsible for managing machine states and registers. • Fatal errors are handled by UNIX signal facility. Trusted modules may use a timer facility to interrupt execution or determinate a call.

15. Allows a fault domain to safely call the a trusted stub routine outside its domain; that stub then safely calls into the destination domain. Each jump table entry is a control transfer instruction whose target address is a legal entry point outside the domain. Because the table is kept in the (read-only) code segment in the fault domain, it can only be modified by a trusted module. Jump Table

16. Performance result

17. Performance result

18. Performance result

19. Performance result

20. Conclusion • Despite of the 4% overhead in sandboxing technique in executing distrusted code, this method yields best application performance. • whole approach does not enforce the privacy aspect of security, since addresses used in load instructions are not checked or sandboxed, because to do so would be prohibitively expensive.

21. References • Tom Burkleaux ‘ s Slides for Fault domain and cross fault domain communication (figs) on Efficient software based isolation • Carl Yao’s slides for Examples of segment matching and address sandboxing Slides on efficient software based isolation-Sandboxing • SFI-Risc .pdf