Higher-Order Model Checking and Program Verification Naoki - PowerPoint PPT Presentation

Higher-Order Model Checking and Program Verification Naoki Kobayashi University of Tokyo

What’s This Talk About?  Introduction to – higher-order model checking (model checking of higher- order recursion schemes) – and its applications to automated verification of higher- order functional programs (e.g. “software model checker” for ML)  Discussion on potential applications to automated verification of code generators

Tool demonstration: MoCHi (a software model checker for a subset of OCaml)

Outline  What is higher- order model checking? – higher- order recursion schemes – model checking problem  “Standard” applications to program verification  A pplications to verification of code generators  Conclusion

Higher- Order Recursion Scheme (HORS)  Grammar for generating an infinite tree S → a Order-0 HORS c B (regular tree grammar) B → b S → a c B S B → b S

Higher- Order Recursion Scheme (HORS)  Grammar for generating an infinite tree S → a Order-0 HORS c B (regular tree grammar) B → b S → a c B a S B → b S c b → a → a → a → ... → S a c B c b c b c b S a a c B c b

Higher- Order Recursion Scheme (HORS)  Grammar for generating an infinite tree Order-1 HORS S → A c A x → a x (A (b x)) S: o, A: o → o

Higher- Order Recursion Scheme (HORS)  Grammar for generating an infinite tree Tree whose paths Order-1 HORS are labeled by a m+1 b m c S → A c a A x → a x (A (b x)) c a S: o, A: o → o a b → a → A c → a → ... → a S b c b c a ... c A (b c) b b b A (b(b c)) c b c c

Higher- Order Recursion Scheme (HORS)  Grammar for generating an infinite tree Order-1 HORS S → A c A x → a x (A (b x)) S: o, A: o → o HORS ≈ Call-by-name simply-typed λ - calculus + recursion, tree constructors

Higher-Order Model Checking Given G: HORS A: alternating parity tree automaton ( a formula of modal µ - calculus or MSO), does A accept Tree(G)? e.g. - Does every finite path end with “c”? - Does “a” occur below “b”?

Higher-Order Model Checking Order-1 HORS S → A c a A x → a x (A (b x)) c a S: o, A: o → o a b a b c Q1. Does every finite path end with “c”? b ... YES! b b Q2. Does “a” occur below “b”? c NO! b c

Higher-Order Model Checking Given G: HORS A: alternating parity tree automaton (APT) (a formula of modal µ - calculus or MSO), does A accept Tree(G)? e.g. - Does every finite path end with “c”? - Does “a” occur below “b”? p(x) 2 k-EXPTIME-complete [Ong, LICS06] .. (for order-k HORS) 2 2

TRecS [K. PPDP09] http://www- kb.is.s.u -tokyo.ac.jp/~koba/trecs/  The first practical model checker for HORS  Does not immediately suffer from k -EXPTIME bottleneck  A more recent model checker (HorSat2) can scale up to grammars consisting of 100,000 rules, depending on input

HO Model Checking as Generalization of Finite State/Pushdown Model Checking  order-0 ≈ finite state model checking  order-1 ≈ pushdown model checking ≈ infinite tree transition system a c b a a b c c b Does “a” occur Is there a transition a below “b”? sequence in which “a” occurs after “b”? c b

HO Model Checking as Generalization of Finite State/Pushdown Model Checking  order-0 ≈ finite state model checking  order-1 ≈ pushdown model checking infinite tree ≈ (infinite-state) transition system a a a ... a a c a a b b b ... b c a b c b ... Does “a” b Is there a transition occur b sequence in which c below “b”? “a” occurs after “b”? b

Outline  What is higher- order model checking? – higher- order recursion schemes – model checking problem  “Standard” applications to program verification  A pplications to verification of code generators  Conclusion

From Program Verification to HO Model Checking [K. POPL 2009] HORS Higher-order (describing all program event sequences Model Program + or outputs) Checking Transformation specification + (on events or Tree automaton, output) recognizing valid event sequences or outputs

From Program Verification to Model Checking: Example F x k → + (c k) (r(F x k)) let f x = S → F d  if ∗ then close(x) + else (read(x); f x) c r in + let y = open “foo”  r in c f (y) +  c r ... Is the file “foo”  Is each path of the tree accessed according labeled by r*c? to read* close?

continuation parameter, From Program Verification to Model Checking: expressing how “foo” is Example accessed after the call returns F x k → + (c k) (r(F x k)) let f x = S → F d  if ∗ then close(x) + else (read(x); f x) CPS c r in Transformation! + let y = open “foo”  r in c f (y) +  c r ... Is the file “foo”  accessed according Is each path of the tree to read* close? labeled by r*c?

From Program Verification to Model Checking: Example F x k → + (c k) (r(F x k)) let f x = S → F d  if ∗ then close(x) + else (read(x); f x) CPS c r in Transformation! + let y = open “foo”  r in c f (y) +  c r ... Is the file “foo”  accessed according Is each path of the tree to read* close? labeled by r*c?

From Program Verification to Model Checking: Example F x k → + (c k) (r(F x k)) let f x = S → F d  if ∗ then close(x) + else (read(x); f x) CPS c r in Transformation! + let y = open “foo”  r in c f (y) +  c r ... Is the file “foo”  accessed according Is each path of the tree to read* close? labeled by r*c?

From Program Verification to Model Checking: Example F x k → + (c k) (r(F x k)) let f x = S → F d  if ∗ then close(x) + else (read(x); f x) CPS c r in Transformation! + let y = open “foo”  r in c f (y) +  c r ... Is the file “foo”  accessed according Is each path of the tree to read* close? labeled by r*c?

From Program Verification to HO Model Checking HORS Higher-order (describing all program event sequences) Model Program + + Checking Transformation specification automaton for infinite trees Sound, complete, and automatic for: - A large class of higher -order programs: simply-typed λ - calculus + recursion + finite base types (e.g. booleans) + exceptions + ... - A large class of verification problems: resource usage verification (or typestate checking), reachability, flow analysis, strictness analysis, ...

Predicate Abstraction and CEGAR for Higher-Order Model Checking [K.&Sato&Unno, PLDI2011] f(g,x)=g(x+1) Program is unsafe! Higher-order yes functional program Real error New path? Predicate λ x.x>0 predicates abstraction Error path Higher-order property not satisfied boolean program f(g, b)= Higher-order model checking if b then g(true) else g( ∗ ) property satisfied Program is safe!

Comparison with Traditional Approach Abstraction Traditional Approach of data and control model Safe checking Higher-order Finite state or (functional) systems (maybe) programs unsafe HO Model Checking Abstraction HO model of data checking Safe Higher-order HORS or (functional) (infinite state (maybe) programs systems) unsafe

Applications to Program Verification/Analysis  For functional programs: – Lack of assertion failures, uncaught exceptions, etc. [K+ PLDI2011][Sato+ PEPM2013]... – Tree-processing (e.g. XML processing) programs [K+ POPL10][Ong&Ramsay POPL11]... – Termination/non-termination [Kuwahara+ ESOP14, CAV15] – Temporal properties [Murase+ POPL16] – Exact flow analysis [Tobita+ FLOPS12]  For multi-threaded programs: – Pairwise reachability analysis [Yasukata+ CONCUR14]

Outline  What is higher-order model checking? – higher-order recursion schemes – model checking problem  “Standard” applications to program verification  Applications to verification of code generators (ongoing work with Igarashi)  Conclusion

Simple language for cogen ordinary  M ::= x | v | λ x.M | M 1 M 2 | fix(f, λ x.M) constructs | if M 1 then M 2 else M 3 for FP | gensym() (* symbol generation *) primitives | abs(M 1 , M 2 ) (* code for abstraction *) for | app(M 1 , M 2 ) (* code for application *) constructing code | op(M 1 , M 2 ) (* code for a primitive *) Example: let power n x = if n=0 then one else ∗ (x, power (n-1) x) let powergen n = let x = gensym() in abs(x, power n x) powergen 3 ->* abs(y, ∗ (y, ∗ (y, ∗ (y, one)))) (i.e., λ y.y ∗ y ∗ y ∗ 1)

Expected properties for a code generator  It generates only programs that: – are closed (i.e. “no undefined variables” error) – are well-typed – do not fail (e.g. due to assertion failure) – return expected values – ...

Code generator verification by higher-order model checking?  Model a generated program as a tree abs y *  Code generator is then modeled y * as a (higher-order) tree grammar G y y – let powergen n = let x = gensym() in abs(x, power n x) => Powergen -> Gensym ( λ x. abs x (Power x r))  Model a property on generated programs as a tree automaton A abs – e.g. y occurs only below: y  Use HO model checking to check that all the trees generated by G are accepted by A