DARP workshop on C and C++

1. DARP workshop on C and C++ Colin O’Halloran, Rob Arthan (Lemma1), Phil Clayton

2. Existing Ada Compliance Tool supports verification against Z specs The Ada Compliance Tool is at the heart of the verification technology for Typhoon’s Flight Control System where it currently has formally verified 314 sub-programs as correct and found errors with a further 10 sub-programs. Working towards a C capability like the Ada capability The exploitation route will be to apply this C capability to the Monitoring Unit of the Digital Engine Controller for Typhoon (application funded by Typhoon). It is a very challenging research problem to “tame" C and apply it to Typhoon. Objectives

3. Background • QinetiQ's C♭: a subset of MISRA C designed to be amenable to formal reasoning • MISRA-C: Guidelines for the use of C in critical systems • C Standard “C90" (a.k.a. “C89") [ANSI/ISO 9899:1990] • QinetiQ's semantics of C♭ in Z (O’Halloran) is based on Michael Norrish's thesis that gives a mechanised operational semantics for C in Higher Order Logic.

4. Project Goals • First step towards an industry-strength tool supporting a C Compliance Notation (CCN) • Kit of parts enabling experimentation and evaluation • Short term: self-contained tool with its own front end • Long term: integrated analysis/verification tool with Static Analysis through Abstract Interpretation and Theorem Proving capabilities in synergy

5. Rationale for C♭ • Predictability • Simplicity • Expressive Power • Verification • Evolution

6. Predictability • Side-effects are not allowed in C♭ expressions. • This is largely achieved syntactically by removing side effect expressions or promoting them to the syntactic category of statements. • For example if (x = 1) … and x==2; are syntactically illegal in C♭ since assignment is a statement and equality is an expression not a statement.

7. Predictability • A checking tool with an abstract interpreter checks for healthiness conditions e.g. • absence of language exceptions such as divide-by-zero; • semantic restrictions such as absence of side effects of function calls in expressions. • machine dependent features • Removal of side effects in expressions eliminates the unpredictability of the order of evaluation • The checker produces the following abstract syntax that is being used to define a verification tool.

8. Abstract Syntax of Expressions EXP ::= id_exp(ID) | cons_exp(CONST) | subscript_exp(Subscript_Exp[EXP]) | fun_call_exp(Fun_Call_Exp[EXP]) | comp_sel_exp(Comp_Sel_Exp[EXP]) | unary_exp(Unary_Exp[EXP]) | sizeof_exp(Sizeof_Exp[EXP] ) | sizeof_tname_exp(Sizeof_Tname_Exp[EXP] ) | cast_exp(Cast_Exp[EXP] ) | bin_exp(Bin_Exp[EXP] ) | cond_exp(Cond_Exp[EXP] )

9. Abstract Syntax of Statements STMT ::= compound_stmt(Compound_Stmt[STMT]) | assign_stmt(Assign_Stmt) | pre_stmt(Inc_Dec_Stmt) | post_stmt(Inc_Dec_Stmt) | fun_call_stmt(Fun_Call_Stmt) | void_fun_call_stmt(Fun_Call_Stmt) | if_stmt(If_Stmt[STMT] ) | switch_stmt(Switch_Stmt[STMT] ) | while_stmt(While_Stmt[STMT] ) | do_stmt(Do_Stmt[STMT] ) | for_stmt(For_Stmt[STMT] )

10. C♭ Summary • Expressions consist of function calls, casts, the logical and mathematical operators and the ternary conditional • Statements consist of function calls, if, switch, for, do, while, simple and compound statements, assignment, ++ and -- • goto and continue are not permitted • break is only permitted in a limited form in switch statements • the switch statement is given a specific syntax with case only allowed at the outer level of the switch body. Each case statement must end in a break and a default statement must also be included.

11. Technical Approach to Verifying C♭ • ProofPower provides a powerful development platform • Programmable support for specification and proof in HOL • Supports multiple object languages (HOL, Z, . . . , now C) • parser generator, generic pretty-printing tools • comprehensive libraries for syntax manipulation • Standard ML language is safe and powerful • Take C90 standard as basis for front end • Support full C syntactically for future expansion • Parsing full C is fairly unproblematic • Exploit MISRA and C♭ rules to give tractable semantics • Capture semantics in explicit Z definitions where possible • Soundness of VC generation, e.g., for switch statements

12. Reasoning about Pointers • Classical Hoare logic exploits equivalence between: • Semantics of assignment in programming • Semantics of substitution in logic • Classical weakest pre-condition rule: • WP(X := E; G) ≙ G[E=X] E.g., WP(B := 2;A = B) ≙ A = 2 • Classical Hoare logic breaks down for assignment via pointers: • E.g. in C (where assignment is written = ) int i, *pi; pi = &i; *pi = 2 • Second assignment changes i without mentioning it • Naive translation into logic unsound and incomplete

13. Reasoning about Pointers • Solution (Norrish, O'Halloran) uses an explicit model of store supporting two logically connected views: • Low level `store as byte array' view, • High level `variables and values' view • CCN Toolkit provides a Z model of the store semantics and the types, values and operations of C

14. CCN Toolkit Model of Store • Assignment specified implicitly:

15. Weakest Precondition Calculation • General rule for specification statement: WP(Δw [pre,post], G) ≝ pre[w’/w]  (∀W’’ . post[w’’/w’][w’/w] ⇒ G[w’’/w’]) • Model general assignment as assignment to the store, σ: • Detect special cases where the classical rule is valid • Trick with Z quantification unites general and special treatments (“allocation schema" asserts that low and high level views agree)

16. Weakest Precondition Calculation • Only assignment is problematic! • Structured programming constructs are classical, e.g., • Core weakest pre-condition calculation complete • Relatively straightforward to flesh out remainder • Details likely to depend on interaction with static analysis

17. C Value Domain • Use a so-called “deep embedding" of the value domains: • Generality and simplicity of translation • E.g.

18. Representing Program Variables • A C variable x corresponds to two Z objects xl and xv: • xl is a constant to represent the type and address (which is left unspecified), e.g., if x has C type double: • xv is a variable of type VALUEC to represent the value in assertions

19. Simple Demonstration of Verification Condition Generation • An example C Compliance Notation script • Currently use Z for pre- and post-conditions • Presentation layer will allow C subset in future

20. px x Int x, *px; &x void init_x(void) x, px [ ┌Z xv’ = IntValC 2 ┐ ] { } px = &x; 2 *px = 2;

21. Simple Demonstration of Verification Condition Generation • Example script gives rise to a VC as follows:

22. Larger Example Demonstration

23. Larger Example Demonstration

24. Larger Example Demonstration

25. Remarks • Rather verbose compared with Ada Compliance Tool • Reflects generality of deep embedding scheme • Reflects treatment of pointers uniting low and high level views • No scalability problems envisaged (constant overhead) • Not difficult to handle programmatically • Aim to provide a C-like presentation layer for end-users • Developing robust C front end that enforces Healthiness Conditions • Fully specified formal semantics (rather than current axiomatic under-specification) needs to be added • Proof theory and Verification Condition generation needs development to produce provable Verification Conditions, i.e. if the VC is true is there sufficient information available to prove that it is true (currently insufficient information for the stack example).

26. Conclusions and Future Directions • Helps validate C♭ formal semantics in Z • Have a good basis for further developments • Notation is verbose but by no means intractable • Investigate potential synergy between: • Abstract Interpretation • formal reasoning (ProofPower, C Semantics in Z) • Exploitation on Typhoon DECMU code • C front end needs to be made robust • Subtle issues concerning semantics, implementation and formal proof to be resolved • C♭ can be readily extended both syntactically and semantically to even deal with side effects, but will proceed cautiously. • Sponsoring extension of Norrish C semantics to C++ - this provides a ready technical route to C♭++