A Fixpoint Calculus for Local and Global Program Flows

1. A Fixpoint Calculus for Local and Global Program Flows Swarat Chaudhuri, U.Penn (with Rajeev Alur and P. Madhusudan)

2. Software model-checking Model M(pushdown for interprocedural; finite-state for intraprocedural) Code Abstraction Flow sensitive Specification Modelchecker Does M satisfy f? Logical formula (f) Yes/No mu-calculus, LTL, CTL…

3. Logics for software model-checking mu-calculus • Canonical temporal logic • Fixpoints over sets of states • Suitable for symbolic implementation • Equivalent to alternating tree automata • Decidable model-checking on pushdown systems LTL CTL Is the mu-calculus the best specification logic for procedural programs?

4. Problem #1 The mu-calculus cannot capture all properties of interest in pushdown models. write(v) local ret call local local local call ret ret call local local Reachability: Is write(v) reachable? In mu-calculus, Local reachability: Is write(v) reachable in the current context?

5. Problem #2 Model-checking the mu-calculus on pushdown systems is decidable. But… Reachability in mu-calculus: Formula describes a terminating symbolic computation in finite-state systems (intraprocedural analysis). Application: mu-calculus is the “assembly language” in temporal logic model-checkers like NuSMV. What about pushdown models (interprocedural analysis)?

6. Our contributions VP-mu • Local, context-sensitive reachability • Interprocedural dataflow involving local + global variables • Pre/post-conditions • Stack inspection • Pushdown games • Access control LTL CTL mu-calculus VP-mu: EXPTIME Mu-calculus, CTL: EXPTIME Reachability games: EXPTIME Formulas encode symbolic, interprocedural summary computations

7. Local reachability local ret call local local local call ret ret call local local write(v) • Is write(v) reachable in the current context? • To jump across contexts, specification needs to have a stack. • Unfortunately, model-checking pushdown specifications onpushdown models is undecidable.

8. Visibility; structured trees Tree model = Unfolding of the graph of configurations of a procedural program Node of tree = control state + stack + history Procedure structure visible via an edge labeling p call ret call local foo bar local ret local p p q ret bar local ret p foo call ret ret bar local p q

9. Summary trees local Summary call s call s local ret ret local v ret v ret u u p Matching returns of s = {u,v} local local Visibility lets us chop a tree into subtrees that summarize contexts. We could jump across contexts if we could reason about concatenation.

10. Logics on subtrees s Mu-calculus formulas can be interpreted at subtrees rather than nodes Formulas  sets of subtrees Modalities argue about full subtrees rooted at children local u Why not a fixpoint calculus where: Formulas  sets of summary trees and modalities argue about concatenation? Enter VP-mu.

11. Reasoning using summaries Formulas sets of summariesTrees are possibly infinite (unmatched paths) s call s ret local u

12. One-step local reachability s call local u ret

13. Colored summary trees Number of “leaves” is unbounded Solution: assign leaves k colors Colors are defined by formulas on demand call ret

14. Using colors call q 1

15. Local reachability Use a variable X to store sets of summaries Compute a fixpoint of summaries call • Summaries plugged into computation • Symbolic computation • Does this remind you of interprocedural dataflow analysis? 1 1 Reach a leaf colored 1:

16. The mu-calculus vs VP-mu VP-mu: fixpoints over summary trees The mu-calculus: fixpoints over full subtrees

17. Global and local program flow Very busy expression e (x): Along all paths, use (e) appears before x is written. If x is local, use local reachability-like spec. If e involves local as well as global variables, trackthem using a combination of reachability and localreachability.

18. Other properties • Many other context and flow sensitive dataflow properties • Pre/post-conditions: If P is satisfied at a call and R holds within its scope, then Q holds on return. • Stack inspection: • If control reaches an unsafe procedure, then a guaranteeing procedure must be on the stack. • If control has ever been in an unsafe procedure, then P must hold so long as control is in a critical procedure. • Games where some procedures are owned by Attacker and others are owned by Protector. • Access control, stack boundedness…

19. Model-checking foo Configuration of an interprocedural control-flow graph : bar u v Node of a tree: bar History doesn’t matter (no past operator) x Enough to consider stackless summaries. But they are finite in number! Same symbolic algorithm as for the mu-calculus (stackless summaries replacing states). Configuration for matching returns: Stack stays thesame betweencall and matching return Stackless summaries:

20. Expressiveness • The mu-calculus is contained in VP-mu. • CARET (Alur, Etessami, Madhusudan 2004) is contained in VP-mu. • Satisfiability of VP-mu is undecidable. Even monadic second-order logic on trees has decidable satisfiability. • Subsequent result: • VP-mu = visibly pushdown alternating parity tree automata • [Visibly pushdown tree languages – Alur, Chaudhuri, Madhusudan. Submitted; draft available on homepage] • Analog of equivalence between the mu-calculus and alternating parity tree automata.

21. Conclusions VP-mu • Local, context-sensitive reachability • Interprocedural dataflow involving local + global variables • Pre/post-conditions • Stack inspection • Pushdown games • Access control LTL CTL mu-calculus VP-mu: EXPTIME Mu-calculus, CTL: EXPTIME Reachability games: EXPTIME Mu-calculus: Intraproceduralfixpoints VP-mu: Interprocedural fixpoints

22. Current work • Modular specifications for static analysis and security. A model-checker for C code applying ideas presented here. • A unified theory of visibly pushdown automata, fixpoint calculi over summaries, and quantifier logics.