Lecture: seL4

Comprehensive Formal Verification of an OS Microkernel, TOCS 2014, pp. 2:1–2:32 and seL4 Reference Manual, chapter 2

Questions

Question

Figure 3 describes the various proofs at work in seL4 and how they interact. List two types of bugs that can be prevented by these proofs (be specific about by which proof), as well as two types of bugs that cannot be prevented by these proofs.

Question

How does memory allocation work in seL4? For example, if an application wishes to allocate a new page at virtual address 0x10000000, what operations need to be performed by the kernel?

Question

Suppose we wanted to apply the seL4 methodology to verifying an OS kernel like EROS or HiStar. What would the specification be like? What kinds of changes might be needed to the design and implementation?

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).

For example, in the conclusion, formally verified software is less expensive to develop than traditionally engineered “high-assurance” software and that the cost is only about a factor of two higher than industry-standard software. Do you agree?

“verification” is overloaded
- interaction verification
- automated verification (SMT)
- bounded model checking
- testing
- static analysis
- manual auditing
examples of efforts
- compilers
  - 1967: Correctness of a compiler for arithmetical expressions, McCarthy & Painter
  - 1972: Proving compiler correctness in a mechanized logic, Milner & Weyhrauch
  - 2009: CompCert
- OS kernels
  - 197x-1980: UCLA Unix security kernel - finished 90%+ spec and 20%- proof
  - 198x: Kit
  - 2009: seL4
  - more recent: Ironclad, CertiKOS, Hyperkernel
what does verification provide
- a mechanical proof that the impl “meets” the spec
- assume a correct proof checker
cost
- verification effort, run-time performance, compability, learning curve
- seL4: ~10K lines of code, ~200K lines of proof, “about 25–30 person years, to do this again it would be about 10 person years”
- Ironclad: ~7K lines of code, ~33K lines of proof, 3 person-years
- Hyperkernel: “push-button” veriifcation
general questions
- what’s the TCB (trusted computing base): spec, tools, environment
- is the spec reasonable
  - expressive enough to prevent bugs
  - simple enough for human review
- is the proof effort reasonable
  - should we use verification in daily software development
  - economy issue & human factors
- is the performance reasonable
  - is the impl is good for practical use (or, too trivial in order to simplify verification)
  - is it possible for verification to catch up with implementation
focus of this class: specification & system design
- what bugs does the specification prevent (and what doesn’t)?
- verifiability as a first-class design goal
- take 505/507 if you wanted to learn more about formal methods
sel4
- what are the specifications/theorems
  - state-machine refinement
  - machine-code correctness (translation validation)
  - IFC (noninterference/nonleakage)
  - worst-case execution time analysis
- kernel design
  - single kernel stack
  - kernel-user transitions (mostly atomic)
    - interrupts disabled in the kernel (mostly)
    - interrupt points - why?
  - represent resources explicitly as capabilities
    - no implicit memory allocation in the kernel
    - capability derivation tree: implications
    - programmability: handle physical memory, CSpace, CDT, virtual memory address space
  - why the Haskell prototype
- implementation
  - constraints on C
  - constraints on gcc (e.g., -O2)
- machine model
  - hardware spec: controlling timer, interrupts, TLB, etc.
  - what are not modeled? can we do better?