daniel jackson static analysis symposium

1
daniel jacksonstatic analysis symposium
santa barbara june 2k
logic,models analysis
2
my green eggs and ham

• two languages in any analysis
• first order relational logic
• models in their own right

3
plan of talk

• Alloy, a RISC notation
• models of software
• analysis reduced to SAT
• finding bugs with constraints

4
an example

• model CeilingsAndFloors domain Man, Platform
  state ceiling, floor Man -gt Platform!
• // one mans ceiling is another mans floorinv
  all m Man some n Man - m m.ceiling
  n.floor
• // one mans floor is another mans
  ceilingassert all m Man some n Man - m
  m.floor n.ceiling

5
kernel type decls

• d decls, x typexps, t types
• d v xx t t -gt t t gt x
• sample decls
• File, Dir, Root Object
• dir Object gt Name -gt Object
• entries Object -gt DirEntry
• name DirEntry -gt Name
• contents DirEntry -gt Object
• parent Object -gt Object

6
kernel expressions

• f formulas, e exps, v vars
• e e e e e e - e set ops e
  e relational ops e . e image
  e v application v t
  f comprehension v
• sample exprs
• Root.parent File
• d.entries.contents
• n.dir d

7
kernel formulas

• f e in e subset f f !f logic
  ops all v t f quantification
• sample formulas
• FileDir-Root in Root.parent
• all d DirEntry ! d in d.contents.entries

8
shorthands

• declarations
• domain d declares d _d
• use sets on RHS
• multiplicities ?1, ? ?1, ! 1
• domain Object, DirEntry, Namestate
  partition File, Dir Object Root Dir
  ! entries Dir ! -gt DirEntry name DirEntry -gt
  Name ! contents DirEntry -gt Object ! parent
  (children) Object -gt Dir ?

9
more shorthands

• quantifiers
• sole v t f ? some w t v t f in w
• all x f ? all x d f where d is inferred
  domain
• Q e ? Q v v in e
• sample invariants
• // object has at most one parent
• all o sole o.parent
• // root has no parents
• no Root.parent
• // all other directories have one parent
• all d Dir - Root one d.parent

10
sample model intentional naming

• INS
• Balakrishnan et al, SOSP 1999
• naming scheme based on specs
• why we picked INS
• naming vital to infrastructure
• INS more flexible than Jini, COM, etc
• what we did
• analyzed lookup operation
• based model on SOSP paper Java code

11
intentional naming

• attribute/value pairs
• ?city cambridge?
• hierarchical specs
• ?city cambridge, building ne43, room 524?
• ?service camera, resolution hi?
• ?service printer, postscript level2?
• lookup
• database maps spec to set of records
• query is set of specs
• lookup returns records meeting all specs

12
tree representation
13
strategy

• model database queries
• characterize by constraints
• generate samples
• check properties
• obvious
• no record returned when no attributes match
• claims
• wildcards are equivalent to omissions
• essential
• additions to DB dont reduce query results
• discuss and refine

14
alloy model state

• model INS domain Attribute, Value,
  Recordstate Root fixed Value! valQ
  Attribute? -gt Value? attQ Value? -gt Attribute
  valDB Attribute? -gt Value attDB Value?
  -gt Attribute rec Value -gt Record lookup
  Value -gt Record

15
alloy model constraints

• // Root is not the value of an attributeinv Q1
  no Root.valQ
• // if query and DB share a leaf value, lookup
  returns its recordsinv Lookup1 all v no
  v.attQ no v.attDB -gt v.lookup v.rec
• // adding a record doesnt reduce resultsassert
  LookupOK7 AddRecord -gt Root.lookup in
  Root.lookup'

16
checking assertions
3 attrs,vals, recs
selectscope
runcheck
fixmodel
incrscope
counter?
N
Y
N
N
real?
slow?
Y
Y
propfails
propholds
17
results

• 12 assertions checked
• when query is subtree, ok
• found known bugs in paper
• found bugs in fixes too
• monotonicity violated

18
counterexample
19
time effort

• costs
• ? 2 weeks modelling, 70 50 lines Alloy
• cf. 1400 900 lines code
• ? all bugs found in lt 10 secs with scope of 4
• 2 records, 2 attrs, 3 values usually enough
• cf. a year of use
• ? exhausts scope of 5 in 30 secs max
• space of approx 1020 cases

20
other modelling experiences

• microsoft COM (Sullivan)
• automated simplified 99 lines
• no encapsulation
• air traffic control (Zhang)
• collaborative arrival planner
• ghost planes at US/Canada border
• PANS phone (Zave)
• multiplexing conferencing
• light gets stuck

21
why modelling improves designs

• ?rapid experimentation
• ?articulating essence
• ?simplifying design
• ?catching showstopper bugs

22
how analyzer works

• what you learned in CS 101
• 3-SAT first NP-c problem
• to show a problem is hard
• reduce SAT to it
• what we know now
• SAT is usually easy
• to show a problem is easy
• reduce it to SAT
• key to reduction
• consider finite scope type ? ?

small scope hypothesis most interesting
caseshave illustrationsin small scopes
23
architecture
alloyproblem
alloyresult
translateproblem
translatesolution
mapping
scope
booleanformula
booleansolution
SATsolver
24
example

• problem
• a, b S
• p S -gt T
• ! (a b).p in (a.p b.p)
• a model in a scope of 2
• S S0, S1
• T T0, T1
• p (S0, T0), (S1, T0)
• a S0
• b S1

25
translation scheme

• represent
• set as vector of bool var
• a a0 a1
• b b0 b1
• relation as matrix
• p p00 p01 , p10 p11
• translate
• set expr to vector of bool formula
• XT a - bi XT ai ? ?XT bi
• XT a . bi ?j. XT aj ? XT bji
• relational expr to matrix of bool formula
• formula to bool formulas

26
translation

• a a0 a1
• b b0 b1
• p p00 p01 , p10 p11
• a b a0 ??b0 a1 ? ?b1
• (a b).p (a0 ??b0 ? p00) ? (a1 ? ?b1 ? p10)
• a.p (a0 ? p00) ? (a1 ? p10) (a0 ? p01) ? (a1
  ? p11)
• b.p (b0 ? p00) ? (b1 ? p10) (b0 ? p01) ? (b1
  ? p11)
• a.p b.p ((a0 ? p00) ? (a1 ? p10)) ?? ((b0 ?
  p00) ? (b1 ? p10))
• ! (a b).p in (a.p b.p) ? (((a0??b0 ? p00) ?
  (a1??b1 ? p10) ? ((a0 ? p00) ? (a1 ? p10)) ??
  ((b0 ? p00) ? (b1 ? p10)))) ?

27
tricks

• quantifiers
• could expand into conjunctions
• but how to make modular?
• translate formula into tree indexed on var
• avoiding blowup
• solvers expect CNF
• standard var intro tricks
• symmetry
• all our domains are uninterpreted
• many equivalent assignments
• add symmetry-breaking predicates

28
how (not) to delete

• class List List next Val val
• void static delete (List p, Val v) List
  prev null while (p ! NULL) if
  (p.val v) prev.next p.next
  return else
  prev p p p.next

29
specifying delete

• basic spec
• p.next p.next c c.val v
• as Alloy model
• domain List, Val
• state
• next List -gt List?
• val List -gt Val?
• p List? , v Val?
• op MergeCode
• op MergeSpec p.next p.next c c.val
  v
• assert MergeCode -gt MergeSpec

30
hacking delete (1)

• counter 1 first cell has value v
• cond Mask p.val ! v
• assert MergeCode Mask -gt MergeSpec

31
hacking delete (2)

• counter 2 two cells with value v
• cond RI all x sole c p.next c.val x
• assert MergeCode Mask RI -gt MergeSpec
• assert MergeCode RI -gt RI

32
step 1 unroll control flow graph
void static delete (List p, Val v) List
prev null while (p ! NULL) if
(p.val v) prev.next p.next
return else
prev p p p.next
33
step 2 encode control flow

• E01 -gt E12 E13E13 -gt E34 E36E34 -gt
  E45E45 -gt E52E36 -gt E67E67 -gt E78E78 -gt E82

34
step 3 encode dataflow

• E36 -gt p3.val3 ! v3
• E45 -gtprev4.next5 p4.next4
• E78 -gt p8 p7.next7

35
frame conditions

• must say what doesnt change
• so add p6 p7
• but
• dont need a different p at each node
• share vars across paths
• eliminates most frame conditions

36
sample results

• on Sagiv Dors suite of small list procedures
• reverse, rotate, delete, insert, merge
• wrote partial specs (eg, set containment on
  cells)
• predefined specs for null deref, cyclic list
  creation
• anomalies found
• 1 unrolling
• scope of 1
• lt 1 second
• specs checked
• 3 unrollings
• scope of 3
• lt 12 seconds

37
promising?

• nice features
• expressive specs
• counterexample traces
• easily instrumented
• compositionality
• specs for missing code
• summarize code with formula
• analysis properties
• code formula same for all specs
• exploit advances in SAT

38
summary

• Alloy, a tiny logic of sets relations
• declarative models, not abstract programs
• analysis based on SAT
• translating code to Alloy
• challenge
• checking key design properties
• global object model invariants
• looking at CTAS air-traffic control
• abstraction, shape analysis ?

39
related work

• checking against logic
• Sagiv, Reps Wilhelms PSA
• Extended Static Checker
• using constraints
• Ernst, Kautz, Selman co planning
• Biere et al linear temporal logic
• Podelskis array bounds
• extracting models from code
• SLAMs boolean programs
• Banderas automata

40

• You do not like them.So you say.Try them! Try
  them!And you may.Try them and you may, I say.

sdg.lcs.mit.edu/alloy