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
call
s
s
local
ret
ret
local
v
ret
v
ret
u
p
u
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 doesnt 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

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.