A Fixpoint Calculus for Local A Fixpoint Calculus for Local and Global Program Flowsand Global Program Flows

Swarat Chaudhuri, U.Penn(with Rajeev Alur and P. Madhusudan)

Software model-checking

Code

Abstraction

Specification

Modelchecker

Yes/No

Model M (pushdown for interprocedural; finite-state for intraprocedural)

Logical formula (f)

Does M satisfy f?

mu-calculus, LTL, CTL…

Flow sensitive

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?

Problem #1The mu-calculus cannot capture all properties of interest in pushdown models.

call

callcall

ret

retret

locallocal

local

local

locallocal

write(v)

Reachability: Is write(v) reachable? In mu-calculus,

Local reachability: Is write(v) reachable in the current context?

Problem #2

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)?

Model-checking the mu-calculus on pushdown systems is decidable. But…

Our contributions

LTL CTL

mu-calculus

VP-mu

VP-mu: EXPTIME

Mu-calculus, CTL: EXPTIME

Reachability games: EXPTIME

• Local, context-sensitive reachability

• Interprocedural dataflow involving local + global variables

• Pre/post-conditions

• Stack inspection

• Pushdown games

• Access control

Formulas encode symbolic, interprocedural summary computations

Local reachability

call

callcall

ret

retret

locallocal

local

local

locallocal

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.

Visibility; structured trees

call

call

call

ret

ret

ret

ret

ret ret

local

local

local

local

local

p

p

p

q

p q

foo

bar

foo

bar

bar

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

Summary trees

call

ret

ret

local

local

local

plocal

s

u

v

Visibility lets us chop a tree into subtrees that summarize contexts. We could jump across contexts if we could reason about concatenation.

call

ret

ret

local

Summary

s

u

v

Matching returns of s = {u,v}

Logics on subtrees

f

local

s

u

Mu-calculus formulas can be interpreted at subtrees rather than nodes

Formulas sets of subtrees

Modalities argue about full subtrees rooted at children

Why not a fixpoint calculus where:

Formulas sets of summary trees

and modalities argue about concatenation?

Enter VP-mu.

Reasoning using summaries

f

local

s

u

flocal

s

Formulas sets of summariesTrees are possibly infinite (unmatched paths)

call

ret

One-step local reachability

local

s

u

call

ret

Colored summary trees

call

ret

Number of “leaves” is unbounded

Solution: assign leaves k colors

Colors are defined by formulas on demand

Using colors

call

q 1

Local reachability

call

1

Use a variable X to store sets of summariesCompute a fixpoint of summaries

1

• Summaries plugged into computation• Symbolic computation• Does this remind you of interprocedural dataflow analysis?

Reach a leaf colored 1:

The mu-calculus vs VP-mu

The mu-calculus: fixpoints over full subtreesVP-mu: fixpoints over summary trees

Global and local program flowVery 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.

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…

Model-checkingConfiguration of an interprocedural control-flow graph :

foobar

Node of a tree:

barx

u

v

Stackless summaries:

Configuration for matching returns:Enough to consider stackless summaries.But they are finite in number!

Same symbolic algorithm as for the mu-calculus (stackless summaries replacing states).

History doesn’t matter (no past operator)

Stack stays thesame betweencall and matchingreturn

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.

Conclusions

LTL CTL

mu-calculus

VP-mu

VP-mu: EXPTIME

Mu-calculus, CTL: EXPTIME

Reachability games: EXPTIME

• Local, context-sensitive reachability

• Interprocedural dataflow involving local + global variables

• Pre/post-conditions

• Stack inspection

• Pushdown games

• Access control

Mu-calculus: Intraproceduralfixpoints

VP-mu: Interprocedural fixpoints

Current work

1. Modular specifications for static analysis and security. A model-checker for C code applying ideas presented here.

2. A unified theory of visibly pushdown automata, fixpoint calculi over summaries, and quantifier logics.