Lecture: verification

preparation

• finish the Hyperkernel exercise

administrivia

• lab X
  • you are encouraged to work in pairs; how to split the work is entirely up to you
  • everyone needs to submit a report
  • no late days
  • if you want to do a demo on Friday, let us know before Wednesday 11am
• final exam
  • similar to past exams
  • focus on JOS and xv6; open book, open laptop, no communication
  • also cover guest lectures and demos

history

• what does verification provide
  • a mechanical proof that the impl “meets” the spec
  • assume a correct proof checker
• some examples of OS verification efforts
  • 197x-1980: UCLA Unix security kernel - finished 90%+ spec and 20%- proof
  • 2009: seL4
  • more recent: Ironclad, Hyperkernel
• cost
  • verification effort, run-time performance, compability, learning curve
  • seL4: “about 25–30 person years, to do this again it would be about 10 person years”
• recent advance in SMT
  • recall last lecture
  • still requires substantial human efforts
  • Ironclad: 3 person-years for 6500 lines of implementation code
• 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

overview

• example: develop a little-endian serializer/deserializer for 16-bit integers
  • encode: n → bytes
  • decode: bytes → n
  • what’s the specification?
• spec v0: forall 16-bit integer n, decode(encode(n)) == n
  • what bugs cannot be captured?
  • is this spec good enough?
    • how about a spec with the detail of little endian
    • how about a spec of just memory safety
• verification: check if a given implementation meets the spec
  • code: le16.c
  • exhaustive testing: check the condition for n from 0 to 65535
  • apply rewriting rules: show LLVM -O2 result constant true
  • pros and cons?
• search for proofs
  • in the input space: check a claim is true for every input; easier to automate; boundedness
  • in the “rewriting” space - rewrite the claim to true; harder to automate