Efficient Software-Based Fault Isolation

1. Efficient Software-Based Fault Isolation By Robert Wahbe, Steven Lucco, Thomas E. Anderson, and Susan L. Graham Presented by Pehr Collins

2. Background: Tannenbaum-Torvalds Debate Linus Torvalds Andrew Tannenbaum

3. Monolithic versus Microkernel • Monolithic OS • Co-locates modules in same address space • Faults in extension code could bring down whole OS or corrupt data • Not safe! • Many developers choose performance over safety • Microkernel OS • Core functions handled by microkernel • Additional functionality added by means of modules in separate address spaces • Faults are isolated • Safe but has a performance cost • Calls between modules required a full context switch • Three orders of magnitude more expensive than normal procedure call to same address space

4. Resolving Conflict Between Safety and Performance • Last week we looked at “Improving IPC by Kernel Design” by J. Liedtke • Optimization techniques could decrease context switch performance penalty to two orders of magnitude for microkernel IPC • Simultaneous with this paper, but still not enough to tip the balance • Enter software-based fault isolation • No more conflict: OS extension code can be both safe and efficient

5. How to Resolve Conflict? Sandboxing • Fault domains are contiguous memory segments used for untrusted modules • Distinguished by unique identifiers • Protection is handled by software in the same address space for all modules

6. Isolating the Fault Domain • Distrusted module code in a fault domain is modified to prevent writing and jumping to outside addresses • This prevents distrusted module from harming other domains • Two ways to accomplish this • Segment matching which pinpoints fault locations • Sandbox addressing which provides no data on source of faults

7. Segment Matching • Most control transfer instructions can be statically verified as address is known at compile time • Checks are added to all other potentially unsafe instructions • Jumps to register address • Stores to register address • Illegal addresses prevented via segment matching • Check if unsafe instruction’s target address has correct segment identifier • If check fails, trap to system error routine outside distrusted module’s fault domain Target Address Segment ID = Upper Address Bits

8. Segment Matching • Requires four dedicated registers • Holds addresses in the code segment • Holds addresses in the data segment • Holds the segment shift amount • Holds the segment identifier • These registers are used only by inserted code, never modified by distrusted module code • Dedicated registers are used to perform the checks on untrusted code • Performance impact of assigning some registers to become dedicated registers is minimal on a RISC system Target Address Segment ID = Upper Address Bits

9. Address Sandboxing • Even better performance than segment matching • Cost: lose the information about the source of the faults • Before each unsafe instruction insert code that sets the upper bits of the target address to the correct segment identifier • Does not catch illegal addresses • Prevents illegal addresses from affecting any other fault domain • But what happens when there is an illegal address? • It just jumps/writes to a garbage location within the fault domain Target Address Segment ID overwrite

10. Address Sandboxing • Requires five dedicated registers • Holds the segment mask • Holds the code segment identifiers • Holds the data segment identifiers • Holds the sandboxed code address • Holds the sandboxed data address Target Address Segment ID overwrite

11. Both Techniques Require Dedicated Registers • Segment Checking: 4 dedicated registers • Address Sandboxing: 5 dedicated registers • What happens if all registers are already allocated by the compiler?

12. Trust/Performance Tradeoff • Only distrusted modules incur performance penalty • Trusted modules can run at full speed • We have covered write and jump, but what about load? • Security can be ramped up to prevent distrusted modules from reading data outside their fault domain • Increases execution time overhead (by quite a bit)!

13. Resource Protection • Fault domains share the same virtual address space • Problem: if a fault domain made system calls it can close or delete files needed by other code in the address space • Could cause crash • Potential solution: modify the OS to know about fault domains •  Not portable • Their solution: resource arbitration

14. Resource Arbitration • Require distrusted modules to access resources through cross-fault-domain RPC • Reserve a fault domain to hold trusted arbitration code • Arbiter determines safeness of system calls by other fault domains • System calls in object code of distrusted modules are transformed to use the arbiter RPC call • Trusted modules make system calls as normal and share fault domain with arbiter

15. How Do Modules Communicate?Cross-fault-domain RPC • Since the whole idea of fault domains is to provide better IPC performance, this is essential • Trusted stubs used for fault domains to call outside their domain • Stubs run unprotected outside caller and callee domains • Stubs copy cross-domain arguments (marshal) and manage machine state • Trustworthiness of stub allows caller and callee to communicate via a shared buffer • This creates a LRPC as only a single shared copy of the data is necessary • Stubs are created manually for now

16. Cross-fault-domain RPC • Jump Table • Allows the untrusted module to call into a stub outside its fault domain • Each entry in the jump table is a legal entry point to a stub outside the untrusted fault domain • Is read only to untrusted module • Is written to by trusted modules to set the entry point addresses

17. Performance Testing • Prototype running on DEC-MIPS and DEC-ALPHA • Considered: • How much overhead incurred by software encapsulation? • How fast is cross-default domain RPC? • Performance impact of using software enforced fault isolation on an application

18. Encapsulation Overhead

19. RPC and Fault Isolation Costs Fault Isolation Overhead in POSTGRES Fault Domain RPC Cost

20. Results Analysis • Savings can be represented by the following formula • Function of: • Time spent in distrusted code (td) • Percentage of time spent crossing fault domains (tc) • Overhead of encapsulation (h) • Ratio (r) of fault domain crossing time to the crossing time of competing hardware based RPC

21. Performance Analysis with Entire Application Encapsulated

22. Performance Analysis with 50% of Application Encapsulated

23. Conclusion • Results are impressive at first glance • Suggest that software based fault isolation is the way to go in many cases where crossing time is sufficiently quicker than standard RPC • However, security, security, security! • When security for reads is desired, overhead shoots way up • from 4.3% on average to 21.8%! • Errors from sandbox addressing difficult to track • Could generate a garbage address inside the fault domain • Stubs are manually generated • Requirement to dedicate 4 or 5 registers could be problematic • Solution is geared towards RISC architecture • Authors mention that CISC systems like 8086 would suffer performance penalties due to dedicated register requirements

24. Thanks for your attention! • Diagrams on Monolithic/Microkernel from Wikipedia • Photos of Linus Torvalds and Andrew Tannenbaum from Wikipedia • Segment Matching and Sandboxing Addressing figures from Tony Bock’s presentation on the same paper (Winter 2006)

25. Quick RecapFault Isolation in cooperating modules: what is the problem? • Existing schemes place each module in own address space • This isolates faults • Major context switch overhead for tightly-coupled modules

26. Quick RecapA Solution in Two Parts • Load code and data for distrusted module into own fault domain • Modify object code of this module to prevent writing jumping to addresses outside fault domain • Portable and language agnostic solutions • Cost is slight increase in execution time for distrusted modules • Yields significant boost in inter-fault domain performance and hence overall performance