Lecture: verification
preparation
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
- testing & verification: see Mars Code
- some examples of OS verification efforts
- cost
- verification effort, run-time performance, compatibility, learning curve
- seL4: “about 25–30 person years, to do this again it would be about 10 person years”
- recent advance in SMT
- still requires substantial human efforts
- Ironclad: 3 person-years for 6500 lines of implementation code
- general questions
- what’s trusted/assumed to be correct: 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