Lecture: SFI

Efficient Software-Based Fault Isolation, SOSP 1993

Question

Briefly describe the software encapsulation techniques proposed in the paper and speculate the performance overhead.

Question

How does SFI prevent malicious code from writing an address outside its domain (in the same address space) through system calls? For example, what if it invokes read(fd, buf, size) where buf points to an address from another domain?

Question

Imagine we are trying to sandbox an x86 binary where the untrusted module can jump to the middle of an instruction. Does this pose problems to the SFI techniques proposed in the paper?

You may be interested in Adapting Software Fault Isolation to Contemporary CPU Architectures. This is just FYI; you don’t need to read it.

Question

Provide a list of questions you would like to discuss in class. Feel free to provide any comments on the paper and related topics (e.g., which parts you like and which parts you find confusing).

fault isolation
- extensible systems: OS kernels, web browsers, databases, editors
- goal: prevent one buggy module from bringing down the entire system
  - trade-offs: safety vs. performance, isolation vs. sharing
  - how other real-world systems deal with this
- techniques
  - virtual machines/replication
  - user-space drivers/process isolation
  - safe languages
    - domain-specific languages: BPF, Lua
    - better C: CCured, Cyclone, SPIN (Modular-3), Singularity (Sing#), Tock (Rust), Biscuit (Go)
      - extra checks at compile-time/run-time
      - some use GC
  - SFI - today
  - bug finding & formal verification
    - SLAM/SDV
    - proof-carrying code
- often combine multiple techniques
  - example: gvisor
  - example: multiprocess tabs, seccomp-bpf, etc. in web browsers
SFI
- threat model
- safety guarantee
- performance impact
- x86-64 and arm
  - variable-length instructions
  - speculative execution, # of registers
  - asm.js/web assembly vs. native client