lecture: How can you trust formally verified software?
Formal verification of software has finally started to become viable: we have examples of formally verified microkernels, realistic compilers, hypervisors etc. These are huge achievements and we can expect to see even more impressive results in the future but the correctness proofs depend on a number of assumptions about the Trusted Computing Base that the software depends on. Two key questions to ask are: Are the specifications of the Trusted Computing Base correct? And do the implementations match the specifications? I will explore the philosophical challenges and practical steps you can take in answering that question for one of the major dependencies: the hardware your software runs on. I will describe the combination of formal verification and testing that ARM uses to verify the processor specification and I will talk about our current challenge: getting the specification down to zero bugs while the architecture continues to evolve.
This is an overview of the 6 year project to create (and publicly release) formal specifications of the Arm processor architecture.
The meat of the talk consists of the things I have done to make the specification correct:
- testing the specification with the test programs that Arm uses as part of the sign-off criteria for processors
- formally validating processor pipelines against the specification (which has the side-effect of finding bugs in the spec)
- formally verifying properties of the specification
- getting lots of different users - they all find different bugs
There are a lot of things that you can do with a formal specification: binary analysis, proving compilers or OSes correct, driving a superoptimizer, etc. so I hope that this will inspire the audience to go off and do something amazing with Arm's specification.
- ARM's v8-A machine readable architecture specification
- HTML files from ARM's v8-A specification
- Tools to dissect ARM's v8-A specification
- Things you can do with the specification