Transcript ppt
Efficient Software-Based Fault Isolation Authors: Robert Wahbe Steven Lucco Thomas E. Anderson Susan L. Graham Presenter: Gregory Netland 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 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 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 - ? 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 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 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 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 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……. 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 • 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 Or Sandboxing • This sets the upper bits to the correct segment identifier • This doesn’t catch, it stops • Verifiable • Takes 5 registers instead of 4 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 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 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 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 Binary patching • System can encapsulate the module by directly modifying object code • Unfornately, a good technique for this does not exist yet • 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 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… Results • How much overhead? • How fast is cross domain fault? 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.