Static and Dynamic Verification of Finite-State Properties

8/3/2019 Static and Dynamic Verification of Finite-State Properties

1/52

Introduction Dynamic Verification Static Verification Conclusion

Static and Dynamic Verification of

Finite-State Properties

Patrick Lam, Jon Eyolfson, Eric Bodden, and

Laurie Hendren

January 2012
http://find/


2/52


Goal

Verify that softwarerespects finite-state

properties.
http://goforward/http://find/http://goback/


3/52


Sample Finite-state Property

After closing a connection c, dont write to c

until c is reconnected.

conn disconn error

close write

closereconn

reconn, writeclose

write

reconn


4/52


Verification Approaches

Dynamic Verification: implemented runtime verification for

C/C++ using Pin [Eyolfson 2011].

Static/Hybrid Verification: extended CLARA framework toverify properties statically when possible, leaving residual

monitors [Bodden et al 2011].


5/52


Dynamic Verification Approach

Dynamicbinary

translator

Tracerory

Specifications

C/C++ Binary

Monitoring Execution

D S C


6/52


Advantages of Dynamic Verification

Lots of information available at runtime.No need to modify build system.

Can leverage debug symbols.

I t d ti D i V ifi ti St ti V ifi ti C l i


7/52


Tracematch Notation

We specify properties using tracematches:

List of variablesList of symbols

Before or after a function

Optional target and returning objects

Regular expression of symbolsOperating mode (all, only, never)



8/52


Operating Modes

Standard tracematches execute in our never mode, but

we also introduce two novel modes:never: monitor must never reach final state.

all: at program exit, all monitors must be in final state& monitor must never take unlabelled transitions.

only: monitor must never take unlabelled transitions.



9/52


Operating Modes

Advance state

Successful Unsuccessful

In never mode: output

trace if in ending state

In all or only mode:

output trace

Object destroyed or program ends

In all mode: output all traces not in ending

state



10/52


Iterator Tracematch Specification

t ra ce ma tc h U n s a f e V e c t o r I t e r a t o r ( v e c t o r v ,n o r m a l i t e r a t o r i )

{sym c r e a t e i t e r a f t e r r e t u r n i n g ( i ) t a r g e t ( v ) :

v e c t o r : : b e g in ;sym up da te v ec a f t e r t a r g e t ( v ) :

ve ct or : : push back ;sym a c c e s s i t e r b ef or e t a r g e t ( i ) :

n o r m a l i t e r a t o r : : o pe ra to r ;

c r e a t e i t e r a c c e s s i t e r u pda te v ec + a c c e s s i t e r{ never }

}



11/52


Iterator Tracematch FSM

s0 s1 s2 s3create update access

access update

Mode never states this trace should never match.

Two objects: vector v and iterator i.

Should only advance i if it was invalidated by v.

Updates to v = v should not invalidate i.



12/52


Tracematch Monitoring with Pin

At initialization time:

Create data structures from specification.

Insert callbacks associated with symbols.

At runtime:

Keep track of monitored objects in binding table.Callback gets tracematch symbol and actualparameters for variables (0, 1, or 2 objects).



13/52

y

Iterator Example

1 #include

2

3 using namespace st d ;

4

5 i n t main ( )

6 {7 v e c t o r my ve c;

8 my vec . p ush b ack ( 7 ) ;

9 v e c t o r : : i t e r a t o r i t e r = my vec . begin ( ) ;10 my vec . p ush b ack ( 4 2 ) ;

11 i n t x = i t e r ;12 r e t u r n 0 ;

13 }



14/52

y

Iterator Example Output

Tracematch U n s a f e V e c t o r I t e r a t o r o cc ur r ed ,

l i s t i n g t r a c e :

c r e a t e i t e r ( i t e r a t o r c l i e n t . cpp : 9 )

up date v ec ( i t e r a t o r c l i e n t . cpp : 1 0 )

a c c e s s i t e r ( i t e r a t o r c l i e n t . cpp : 1 1 )



15/52

Implementation Structure

Extended Pin dynamic binary translator to

perform runtime monitoring of finite-state

properties.

When program loads relevant functions (often

dynamically), instrument with monitoring code.

Upon calls to monitored functions, advance the

state of the runtime monitor.



16/52

Case Study: AbiWord - Tracematch

Quote from mailing list:

However, I am pretty sure the initialisation at line

1122 needs to be to 0, because 1 results in a call toOpenTable even if there is no table in the document.

Use (open handle+ close)+ tracematch

Recreated by inserting an OpenTable

Tracematch TableUsage d i d n ot hold , l i s t i n g t r a c e :open (wp/ impexp / xp / i e i m p R TF . cpp : 1487 )open (wp/ impexp / xp / i e i m p R TF . cpp : 5219 )



17/52

Overhead



18/52

Problems with Dynamic Approaches I



19/52

Problems with Dynamic Approaches II



20/52

Finite-state Property from Before

After closing a connection c, dont write to c

until c is reconnected.

conndisconn

error

close write

closereconn

reconn, writeclose

write

reconn



21/52

Staged Static Analysis Approach

Note that were reasoning about never properties now.

Remove shadows, using:

Quick Check: dont monitor transitions that are

unreachable or that are along no path to a final state.

Orphan Shadows: like Quick Check, but also take pointer

information into account.

Nop-Shadows: dont monitor transitions that dont change

whether or not the final state is reachable.

If no shadows left, then weve statically proved the property.

Otherwise, we can monitor it at runtime.



22/52

Visualization Tool for Remaining Shadows



23/52

Quick Check by Example

Consider this automaton again:

conn disconn error

close write

closereconn

reconn, write

close

write

reconn



24/52

Quick Check Input: no writes in program

conn disconn error

close

closereconn

close

write

reconn

write

reconn, write write

Input: assume program contains transitions close and

reconn, but not write.



25/52


conn disconn error

close

closereconn

close

write

reconn

write

reconn, write write

Final write transition becomes unreachable, so no need for

any monitoring.



26/52


conn disconn error

close

closereconn

close

write

reconn

write

reconn, write write



27/52

Summary of Quick Check

1 Erase FSM transitions that dont occur in program.

2 Retain only productive FSM states: reachable from initial

state, and can reach final state.3 Retain only productive FSM transitions: to and from

productive states.

4 Return symbols that a) appear in non-looping productive

transitions or b) for which a productive state has nooutgoing transition.



28/52

Orphan Shadows

An extension of Quick Check that takes pointer

information into account.



29/52

Orphan Shadows Example

Connection c1 = new Connection ( . . . ) ,

c2 = new Connection ( . . . ) ;c1 . d is co nn ec t ( ) ;

c2 . wr i t e ( . . . ) ;

Neither the monitors on c1 and c2 will reach a final state, since

c1 and c2 are distinct objects.



30/52

Orphan Shadows Analysis

A shadow is a static program point that causes a finite-state

machine transition; it binds certain FSM variables.

Two shadows are compatible if their bindings may overlap (i.e.

points-to sets are not disjoint).

Approach: run Quick Check once per shadow s, giving the QC

only the shadows compatible with s.



31/52

Nop Shadows

Key idea: use order of transitions.c = new Connection ( . . . ) ;

c . wr i t e ( . . . ) ;

c . d i sc o nn e ct ( ) ;

Clearly, the above code never violates our property.

conn disconn error

close write

closereconn

reconn, write close write

reconn



32/52

Buzzwords: Nop Shadows Analysis

A nop shadow is a shadow that transitions betweenequivalent states, i.e. does not change whether or not theFSM reaches a final state.

Our analysis to detect nop shadows is:

flow-sensitive;

intraprocedural (backwards and forwards passes);

doesnt merge information at control-flow merges;and,

uses interprocedural information from OrphanShadows Analysis.



33/52

Nop Shadows by Example

Two intraprocedural analyses: forward and backward.

c.close()

c.reconnect()

c.write()

0

0 1 2

close write

closereconn


reconn



34/52


Forward analysis: tracks possible FSM states.

0

1c.close()

0 c.reconnect()

0c.write()

0

0 1 2

close write

closereconn


reconn



35/52


Backward analysis: tracks states which must lead to final state.

0 {}

1c.close()

0c.reconnect()

0c.write() {2}

0 {}

0 1 2

close write

closereconn




36/52


Backward analysis: tracks states which must lead to final state.

0 {}{}

1c.close()

{}

0c.reconnect() {1, 2}

0c.write() {2}

0 {}

0 1 2

close write

closereconn




37/52

Continuation-equivalent States

{0} { } = {1} { } = = need not monitor c.close().

0 {}{}

1c.close() {}


0c.write() {2}

0 {}

0 1 2

close write

closereconn




38/52

Non-continuation-equivalent States

But {1} {1, 2} = {0} {1, 2} = keep c.reconnect() for now.

0 {}{}

1c.close() {}


0c.write() {2}

0 {}

0 1 2

close write

closereconn




39/52

Second Pass

After removing close(), other shadows are now nop-shadows.

0 {}

0 {}

0c.reconnect()

{1, 2}

0c.write() {2}

0 {}

0 1 2

close write

closereconn


reconn



40/52

Second Pass

After removing close(), other shadows are now nop-shadows.

0 {}

0 {}

0c.reconnect()

{1, 2}

0c.write() {2}

0 {}

0 1 2

close write

closereconn


reconn



41/52

Algorithm is greedy (and non-optimal)

0 {}{0, 1, 2}

1 c.close() {0, 1, 2}

1c.close() {1, 2}

2c.write() {2}

0 {}



42/52

Algorithm is greedy (and non-optimal)

0 {}{0, 1, 2}

1c.close()

{0, 1, 2}

1c.close() {1, 2}

2c.write() {2}

0 {}

Can only remove one of the close() shadows.



43/52

Accounting for Interprocedural Effects

p u b l i c v oi d m( ) {

}

x.m()

y.n()

(3a)

(3b)

(4)

(2)

(1)method entry

method exit

potentially-

recursive

provably

non-recursive



44/52

Soundness

We proved soundness for our analyses [Bodden 2009 &

TOPLAS submission].

If you can skip a transition aand the set of matching tracesdoesnt change, then transition a is not necessary.

More formally, we must monitor transitions awhere there exists

some trace t such that a= ti t and

matchesL(t1 . . . tn) = matchesL(t1 . . . ti1ti+1 . . . tn).


Reflections


45/52

Role of Points-To Analysis

Example didnt consider pointer analysis.

Strong updates critical for typestate analysis.

Our analysis actually tracks binding

representatives along with states, e.g.

{x {r1, r2}, y {r3}, {x r4}}.

That is, x must alias both objects r1 and r2, y

must alias r3, and x must not alias r4.


Reflections


46/52

Inter- vs. intraprocedural analysis

For our properties on our benchmark programs,

a largely-intraprocedural flow-sensitive

approach suffices.

We also use flow-insensitive interprocedural

information from the Orphan-Shadows analysis.

Naeem and Lhotak are exploring an(expensive!) flow-sensitive interprocedural

approach (IFDS) with strong updates.


Reflections


47/52

Applicability of our technique

We implemented a Certain-Match Analysis:

flags automata that certainly reach the final

state.

Didnt work well: need more than

intraprocedural must-alias information to find

matches that are certain to occur on all paths.


48/52


49/52



50/52

Related Work: Dynamic Monitoring

Dynamic Binary Translators and Rewriters:

Valgrind

(Static) program rewriting frameworks

Runtime Monitoring:

JavaMOP [Chen et al, 2003]Tracematches in AspectJ [Allan et al, 2005]



51/52

Related Work: Static Analyses

Interprocedural, single-object properties [Fink et al]

Interprocedural, flow-sensitive tracematch analysis[Naeem and Lhotak]

Type systems for typestate [DeLine and Fahndrich;

Bierhoff and Aldrich]

Runtime monitor optimizations [Dwyer and Purandare]



52/52

Summary

Presented two approaches to verifying finite-state properties:

Dynamic approach: using Pin dynamic binary translator,50% overhead over Pin alone (which imposes 2200overhead).

Static approach: can often eliminate need for runtime

monitoring for Java programs in our benchmark set.

Documents

Static and Dynamic Verification of Finite-State Properties