Efficient Software-Based Fault Isolation
description
Transcript of Efficient Software-Based Fault Isolation
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 showsignificant 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.