% SFI # administrivia lab 1 - tomorrow lab 2 - May 22 midterm report - May 26 final report - June 5 # goal safely run untrusted modules kernel extensions, browser plug-ins, database UDTs privacy? # approaches trust programmers: kernel modules, ActiveX/NPAPI process isolation / OS sandboxing - Monday SFI - today type-safe languages - next Monday proof-carrying code (OSDI'96, POPL'97) - next spring domain-specific languages: BPF, JS/asm.js (counterexamples?) # demo Native Client: [tutorial, part 1](https://developer.chrome.com/native-client/devguide/tutorial/tutorial-part1) . . . counter-proposals: [jslinux](http://bellard.org/jslinux/), [languages/emscripten](http://repl.it/languages/) # why SFI . . . performance portability: userspace solution smaller(?) TCB compared to capsicum/seccomp support legacy software: games avoid certain hw bugs: reject suspect instructions # overview challenges: no bypass (e.g., indirect jumps), performance rewriter → verifier q: source vs. binary rewriter q: small verifier == trustworthy? # architecture assumptions today's paper: SFI on RISC (Alpha/MIPS) fixed-length, aligned instructions a large number of registers: 5 dedicated regs out of 32 quirks: multithreaded code? self-modifying code? .so? # more pointers SFI on x86: PittSFIeld (USENIX Security'06), MiSFIT, [vx32](http://pdos.csail.mit.edu/~baford/vm/), NaCl SFI on arm/x86-64: the optional reading (USENIX Security'10) SFI for JNI: Robusta (CCS'10) SFI for kernel: XFI (OSDI'06), BGI (SOSP'09), LXFI (SOSP'11) verified verifier: PittSFIeld, RockSalt (PLDI'12) verified w/o verifier: "Portable Software Fault Isolation" (CSF'14)