A Fixpoint Calculus for A Fixpoint Calculus for Local and Global Program Local and Global Program Flows Flows Swarat Chaudhuri, U.Penn (with Rajeev Alur and P. Madhusudan)
Transcript
Slide 1
A Fixpoint Calculus for Local and Global Program Flows Swarat
Chaudhuri, U.Penn (with Rajeev Alur and P. Madhusudan)
Slide 2
Software model-checking Code Abstraction Specification Model
checker Yes/No Model M (pushdown for interprocedural; finite-state
for intraprocedural) Logical formula (f) Does M satisfy f?
mu-calculus, LTL, CTL Flow sensitive
Slide 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?
Slide 4
Problem #1 The mu-calculus cannot capture all properties of
interest in pushdown models. call ret local write(v ) Reachability:
Is write(v) reachable? In mu-calculus, Local reachability: Is
write(v) reachable in the current context?
Slide 5
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
Slide 6
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
Slide 7
Local reachability call ret 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 on pushdown models is undecidable.
Slide 8
Visibility; structured trees call ret local p p p q p q foo bar
foo 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
Slide 9
Summary trees call ret local p 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 local
Summary s u v Matching returns of s = {u,v}
Slide 10
Logics on subtrees 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.
Slide 11
Reasoning using summaries local s u s Formulas sets of
summaries Trees are possibly infinite (unmatched paths) call
ret
Slide 12
One-step local reachability local s u call ret
Slide 13
Colored summary trees call ret Number of leaves is unbounded
Solution: assign leaves k colors Colors are defined by formulas on
demand
Slide 14
Using colors call q 1
Slide 15
Local reachability call 1 Use a variable X to store sets of
summaries Compute a fixpoint of summaries 1 Summaries plugged into
computation Symbolic computation Does this remind you of
interprocedural dataflow analysis? Reach a leaf colored 1:
Slide 16
The mu-calculus vs VP-mu The mu-calculus: fixpoints over full
subtrees VP-mu: fixpoints over summary trees
Slide 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, track them using a combination of reachability and local
reachability.
Slide 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
Slide 19
Model-checking Configuration of an interprocedural control-flow
graph : foo bar Node of a tree: bar x 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 doesnt matter (no past operator) Stack stays the same
between call and matching return
Slide 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.
Slide 21
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: Intraprocedural
fixpoints VP-mu: Interprocedural fixpoints
Slide 22
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.