How much is CompCert’s proof worth, qualification-wise? Xavier Leroy Inria Paris-Rocquencourt Dagstuhl seminar “Qualification of FM tools”, April 2015 1 / 29
In this talk Some thoughts on taking advantage of CompCert’s correctness proof in a DO-330-style tool qualification. Based on discussions with two aircraft manufacturers, and work done in ANR project Verasco ( http://verasco.imag.fr/ ). 2 / 29
In this talk Some thoughts on taking advantage of CompCert’s correctness proof in a DO-330-style tool qualification. Based on discussions with two aircraft manufacturers, and work done in ANR project Verasco ( http://verasco.imag.fr/ ). Disclaimer 1: all this is speculation. Qualification of a C compiler has never been attempted before, and may not be viable economically speaking. Disclaimer 2: the views presented here are mine and are not endorsed by said manufacturers. Disclaimer 3: my understanding of tool qualification is very limited. 2 / 29
The formally-verified part of CompCert parsing type elim. side-effects CompCert C Clight C # minor out of expr loop simplif. stack allocation Optimizations: constant prop., CSE, of variables dead code, inlining, tail calls CFG constr. instruction RTL CminorSel Cminor expr. decomp. selection Value and register allocation (IRC) neededness calling conventions analyses layout of linearization LTL Linear Mach of the CFG stack frames asm code generation Asm x86 Asm ARM Asm PPC 3 / 29
A possible mapping to DO-330 Tool Operational Requirements (High-Level) Tool Requirements Low-Level Tool Requirements Source code
A possible mapping to DO-330 Tool Operational Requirements English prose (High-Level) Tool Requirements Coq specs Low-Level Tool Requirements Coq code Source code OCaml code
A possible mapping to DO-330 Tool Operational Requirements English prose Manual verification (High-Level) Tool Requirements Coq specs Automated verification (Coq proof checking) Low-Level Tool Requirements Coq code Automatic code generation (Coq’s extraction mechanism) Source code OCaml code 4 / 29
Partitioning the Coq development The specifications: everything involved in the statement of semantics preservation. • Abstract syntax and operational semantics for CompCert C. • Abstract syntax and operational semantics for Asm. • Notions of semantic preservation: backward simulation diagrams OR preservation of whole-program observable behaviors. • Supporting theories: integers, floating-point numbers, memory states, observable events. 5 / 29
Example of specification The semantics of sequencing in CompCert C Inductive sstep: state -> trace -> state -> Prop := [...] | step_seq: forall f s1 s2 k e m, sstep (State f (Ssequence s1 s2) k e m) E0 (State f s1 (Kseq s2 k) e m) | step_skip_seq: forall f s k e m, sstep (State f Sskip (Kseq s k) e m) E0 (State f s k e m) | step_continue_seq: forall f s k e m, sstep (State f Scontinue (Kseq s k) e m) E0 (State f Scontinue k e m) | step_break_seq: forall f s k e m, sstep (State f Sbreak (Kseq s k) e m) E0 (State f Sbreak k e m) 6 / 29
Partitioning the Coq development The specifications: everything involved in the statement of semantics preservation. The code: algorithms for code generation and optimization; supporting static analyses. • Programmed in Coq’s specification language (Gallina). • Pure functional style: recursive functions operating by pattern-matching on tree-shaped data structures. • Uses monads for mutable state and error reporting. • Similar to Haskell code or pure OCaml code. 7 / 29
Example of Coq code Building a control-flow graph for a structured expression Fixpoint transl_expr (map: mapping) (a: expr) (rd: reg) (nd: node) {struct a}: mon node := match a with | Evar v => do r <- find_var map v; add_move r rd nd | Eop op al => do rl <- alloc_regs map al; do no <- add_instr (Iop op rl rd nd); transl_exprlist map al rl no | Eload chunk addr al => do rl <- alloc_regs map al; do no <- add_instr (Iload chunk addr rl rd nd); transl_exprlist map al rl no | [...] end. 8 / 29
Partitioning the Coq development The specifications: everything involved in the statement of semantics preservation. The code: algorithms for code generation and optimization; supporting static analyses. The proof: everything that contributes to showing that the code satisfies the semantic preservation specs. • Abstract syntax and semantics of intermediate languages. • Many other auxiliary definitions. • Copious proof scripts. 9 / 29
Smaller high-level requirements Thanks to the Coq proof, the high-level requirements do not need to talk about: • Intermediate languages. • Compilation algorithms. • Optimizations and their supporting static analyses. “Draw me a compiler.” “The compiler is in this box.” 10 / 29
Partitioning the Coq development The three aspects (specs, code, proofs) are intertwined in the current CompCert development, and difficult to separate without tool assistance. Theorem transf_c_program_preservation: forall p tp beh, transf_c_program p = OK tp -> program_behaves (Asm.semantics tp) beh -> exists beh’, program_behaves (Csem.semantics p) beh’ /\ behavior_improves beh’ beh. Proof. ... Qed. (Caption: Specs; Code; Proof.) Also: some definitions belong both to the specs and to the code. Also: bits of proofs in the code (dependent types). 11 / 29
Verification activities Between high-level and low-level requirements: fully automated Coq proof checking. • Checked at every Qed. in interactive proof mode. • Re-checked by coqc batch compilation. • Re-re-checked by the coqchk validator. (But: not independent, and doesn’t work currently.) 12 / 29
Verification activities Between high-level and low-level requirements: fully automated Coq proof checking. Between low-level requirements and source code: Coq’s extraction mechanism. + Automatic code generation. – Need to increase confidence. (No real test suite; few users.) + Generated OCaml code looks a lot like the Coq code. – But too big for manual code review. (30 000 LOC + 20 000 LOC for the generated parser.) 13 / 29
Example of extracted code let rec transl_expr map a rd nd s = match a with | Evar v -> (match find_var map v s with | Error msg0 -> Error msg0 | OK (a0, s’) -> add_move a0 rd nd s’) | Eop (op, al) -> (match alloc_regs map al s with | Error msg0 -> Error msg0 | OK (a0, s’) -> (match add_instr (Iop (op, a0, rd, nd)) s’ with | Error msg0 -> Error msg0 | OK (a1, s’0) -> transl_exprlist map al a0 a1 s’0)) | Eload (chunk, addr, al) -> (match alloc_regs map al s with | Error msg0 -> Error msg0 | OK (a0, s’) -> (match add_instr (Iload (chunk, addr, a0, rd, nd)) s’ with | Error msg0 -> Error msg0 | OK (a1, s’0) -> transl_exprlist map al a0 a1 s’0)) 14 / 29
Verification activities Between high-level and low-level requirements: fully automated Coq proof checking. Between low-level requirements and source code: Coq’s extraction mechanism. Between operational and high-level requirements: here are dragons! • The notion of semantic preservation needs explaining. • Asm semantics is not too hard to relate with the processor’s documentation. • The CompCert C semantics is complex, and the ISO C99 standard is a mess → difficulties relating the two. 15 / 29
Validating a formal C semantics By reviews: • Need to be fluent in Coq and expert on the C standard. • About 2500 LOC of Coq + 5000 for the supporting theories. By formal proofs of equivalence with other semantics: • E.g. Norrish’s Cholera (HOL), Krebber’s CH2O (Coq). • Different subsets of C, different refinements. • The other semantics haven’t been validated either! By testing: • Using an executable presentation of the semantics. • Much easier to test than a whole compiler, because no optimizations and no context dependencies. • Also: identifies undefined behaviors precisely. 16 / 29
The CompCert C reference interpreter An interpreter for C, written in Coq, proved sound and complete against the operational semantics. Several levels of tracing: • -quiet : only prints program outputs • default: prints all observable actions (e.g. volatile accesses) • -trace : full trace of execution steps. Several ways to handle C nondeterminism: • Pick one, fixed evaluation order. • Randomize the evaluation order. • Explore all possible evaluation orders. Example of use: 3-way differential random testing (CompCert interpreter, CompCert compiler, GCC) using Csmith. 17 / 29
The full CompCert compiler preprocessing, parsing, construction of an AST C source AST C elaboration, type-checking, de-sugaring Verified compiler Type reconstruction Register allocation Code linearization heuristics assembling printing of Assembly Executable AST Asm linking asm syntax Not proved Proved in Coq Verification needed (hand-written in Caml) (extracted to Caml) No additional verification needed 18 / 29
What to do with the unproved parts? Assembly and linking: • An unverified validation tool that matches the ELF executable against the Asm AST. From C source to CompCert C AST: • Testing? (mostly local, compositional transformations) • Proving more things? (e.g. lexing) • Lack of high-level formal specifications. 19 / 29
Recommend
More recommend
