Paper: "XFI: Software Guards for System Address Spaces"
XFI: Software Guards for System Address Spaces
Úlfar Erlingsson, Microsoft Research, Silicon Valley; Martín Abadi, Microsoft Research, Silicon Valley, and University of California, Santa Cruz; Michael Vrable, University of California, San Diego; Mihai Budiu, Microsoft Research, Silicon Valley; George C. Necula, University of California, Berkeley
Úlfar Erlingsson, Microsoft Research, Silicon Valley; Martín Abadi, Microsoft Research, Silicon Valley, and University of California, Santa Cruz; Michael Vrable, University of California, San Diego; Mihai Budiu, Microsoft Research, Silicon Valley; George C. Necula, University of California, Berkeley
Abstract
XFI is a comprehensive protection system that offers both flexible access control and fundamental integrity guarantees, at any privilege level and even for legacy code in commodity systems. For this purpose, XFI combines static analysis with inline software guards and a two-stack execution model. We have implemented XFI for Windows on the x86 architecture using binary rewriting and a simple, stand-alone verifier; the implementation's correctness depends on the verifier, but not on the rewriter. We have applied XFI to software such as device drivers and multimedia codecs. The resulting modules function safely within both kernel and user-mode address spaces, with only modest enforcement overheads.
posted by Jeff Mogul at 5:28 PM
3 Comments:
I found your talk very interesting, and had wanted to ask you a question regarding interactions between un-instrumented and instrumented code. Specifically when instrumented code has to update a parameter passed to it by un-instrumented code (and also how control flow transitions between the two types of code are handled). i.e. is there a default policy where the un-instrumented code is just somehow considered 'trusted' (and all of its data memory usage somehow tracked)?
-thanks
-Anurag
Interactions between the host system and XFI modules are handled in large part by "software call gates" (see the paper). Passing a stack parameter by reference can typically be changed in the call gates copy-in, copy-out semantics. For cases with true sharing (not the common case for stack parameters), the call gates can add parameters to slowpath, pointer-accessible memory.
Control flow between host system and the XFI module is also supported by the call gates. Basically, call gates for support routines have to be invoked directly by the XFI module (in our implementation, by a verified, permitted reference into the read-only PE-file import table).
The host system is trusted. XFI has no provision for trusting code that doesn't pass verification (i.e., un-instrumented code). There might be ways of establishing trust in those cases (e.g., by using machine-code interpretation), but we have not explored any such options.
XFI: Software Guards for System Address Space
Úlfar Erlingsson, Microsoft Research, Silicon Valley; Martín Abadi, Microsoft Research, Silicon Valley, and University of California, Santa Cruz; Michael Vrable, University of California, San Diego; Mihai Budiu, Microsoft Research, Silicon Valley; George C. Necula, University of California, Berkeley
Presented by Úlfar Erlingsson
Úlfar Erlingsson began his talk by introducing XFI, a software based protection system that provides safe system extension and proceeded with a demo of a JPEG image containing an exploit being rendered by both an unmodified JPEG library and an XFIed version of the library. The first case resulted in an application crash while the XFIed version properly trapped and gracefully aborted the rendering.
XFI creates a safe extension from an existing Windows x86 Portable Executable by performing binary rewriting. The rewriter adds inline guards on computed control-flow transfer using unique labels as valid target identifier. A guard verifies that the label is present at the target site before performing a computed jump or call. This mechanism ensures that all transfers remain within the control-flow graph. The rewriter also adds memory access guards to ensure that computed memory accesses lie within valid memory regions. The validation uses a fast path when the address lies within bounds established at load time. Memory accesses outside of these bounds fall through a slow path which validates the address using data structures similar to page tables. The binary is also modified to use two stacks, a scoped stack and an allocation stack. The scoped stack contains return address and variables that are accessed by name only. The allocation stack contains data that can be access using computed access. This mechanism allows the integrity of the scoped stack to be statically verified.
Because rewriting binaries is a tricky process, XFI doesn't require this step to be trusted. Instead, XFI relies on a trusted verifier to parse the binary at load-time ensuring that binaries have the appropriate structure and the appropriate guards. The verifier is simple, fast and consist of only 3000 lines of code, increasing confidence in its correctness.
Bryan Ford from MIT asked how XFI prevents code from jumping into the heap. Úlfar answered that the target identifier has to match for a jump to proceed and the verifier ensures that identifiers are unique. Jim Lawson from MSB Associates asked if XFI rejects self modifying code. Úlfar acknowledged.
Rik Farrow asked about binary size increase. Ulfar answered that code can increase by a factor of two or more but that most of the additional code is in the trampolines which are not invoked often. Therefore the increase in code size has a minimal impact on i-cache performance.
Post a Comment
<< Home