Efficient Software-Based Fault Isolation

1. Efficient Software-Based Fault Isolation Authors: Robert Wahbe Steven Lucco Thomas E. Anderson Susan L. Graham Presenter: Gregory Netland

2. The Big Picture • Two Main things: • Loading the distrusted code into its own fault domain • Only mistrusted • Cheaper RPC for cross fault domains • Modify object code so it doesn’t jump to an area it is not supposed to

3. Introduction – More Big Picture Definitions and such • 1993 - what was happening…133mhz, WTC, microkernels • Sandboxing – only slightly increases execution time • Modifying Object Code • Fault Domains – a logically separate portion of the applications address space, and has a uniques identifier which is used to control its access

4. Examples of Programs that could cause problems • PostGres – queries with extension code can play with data not its own or just mess with database in general • BSD (three areas) • Microsoft’s Object Linking • As more things are moved to the user level, more third party code can mess with kernel operations - ?

5. Other Examples • Unix vnode interface – easy to add file system • I/O / Active Messages – compiled into kernel for reasonable performance • Quark Xpress – extension modules can currupt its data structures What does this show significant portion of time being spent in operating system context switch code only a small amount of code is distrusted

6. Why us software and not Hardware • Does not scale with processor integer performance • High Cost for address switching • RPC example: requires at least • A trap into the operating system kernel • Copying each argument from the caller to callee • Saving and restoring registers • Switching hardware address spaces • Possibly flushing the TLB • A trap back to user level • Rinse and repeat

7. Software Enforced Fault Isolation • Going back to the big picture, we have to locate were faults occur in a software module and then we can look at Sandboxing • Cut up the virtual address space into separate chunks

8. Segment Identifier • Divide an applications virtual address space into segments • All virtual addresses share pattern of upper bits • Fault domain has two segments • One for distrusted module’s code • Other for heap, stack, and static data

9. Software Encapsulation • Distrusted code can only jump within its segment, as well as write to its segment, due to the segment identifiers • All legal jumps have same bit pattern • This doesn’t solve all problems, the os will still need to catch illegal things, such as unmapped pages • We have two techniques for this…….

10. Segment matching • Insert Checking code before any unsafe instruction (unsafe means not statically verifiable…jumps through registers - procedure returns, or stores in registers for target address are considered unsafe) • Is it in the correct segment? • If not, trap to system error

11. Uses 4 registers, but not a problem based on their tests can pinpoint the offending instruction, there for better for development Or can skip the pinpointing for efficiency

12. This sets the upper bits to the correct segment identifier This doesn’t catch, it stops Verifiable Takes 5 registers instead of 4 Or Sandboxing

13. Optimizations • Register + offset and guardzones –this avoids uneeded math to compute target addresses. They sandbox reg and not reg + offset to save an instruction. • MIPS stack pointer as a dedicated register and the stack pointer is only sandboxed when set • Transformation tool to remove sandboxing from loops

14. Process Resources • Need to stop multiple fault domains that share the same virtual address space from corrupting per-address-space resources • Let the operating system know • Cross fault domain RPC

15. Data Sharing • Cant work the same way hardware implementation does because hw solution manipulates page table entries in a different way. • Read only is not a problem because fault domains can read any memory within the address space • Read-write through lazy pointer swizzling • Modify hardware page tables to map the shared memory region into every address space segment that needs access • Automatically translates into own segment through sandboxing • Another option is shared segment matching, dedicated registers to hold bitmap that tells which segments the fault domain can access

16. Implementation and Verification • Unsafe regions are areas of code that modify jump dedicated register • Is the dedicated register valid upon exiting the region • Disadvantages • Most modified compilers only support one language • Compiler and verifier must be synchronized • Binary patching can fix these things, however not robust enough

17. Binary patching • System can encapsulate the module by directly modifying object code • Unfornately, a good technique for this does not exist yet

18. Jump table is legal address outside the fault domain Kept in read only, so only modified by trusted code Stubs are unprotected and responsible for copying cross domain arguments

19. Fast communication between fault domains • Calling a trusted stub outside of your domain • Jump table – only modified by trusted code, and legal entry point outside domain • Arguments are passed between fault domains • Because they are trusted, we can copy directly to target domain*** • Fault isolation • In a cross domain call the registers used by the caller and possibly modified by the callee are protected • Switch execution stack • Validate registers • Establish register context for encapsulation • Errors • Addressing violation, loops, etc…

20. Results • How much overhead? • How fast is cross domain fault?

21. Related Work • At this time it was typical to buld micro-kernel operating systems with separate address spaces • This meant heavy ipc with untrusted domains • Performance problems • Some people loaded modules into kernel address space (co-location) • Which means performance over protection • So, this paper is trying to get performance and protection.