static and runtime verification a monte carlo approach state university of new york at stony brook...
TRANSCRIPT
Static and Runtime VerificationA Monte Carlo Approach
State University of New York at Stony Brook
Radu Grosu
Talk Outline
1. Embedded Software Systems
2. Automata-Theoretic Verification
3. Monte Carlo Verification
4. Monte Carlo Model Checking
5. Static Verification of Software-Systems
6. Dynamic Verification Software-Systems
• Systems with ongoing interaction with their environment.
- Termination is rather an error than expected behavior
• Becoming an integral part of nearly every engineered product.
- They control:
Embedded Software Systems
Embedded Systems
Commercial Aircraft
Medical devices
Household devicesTelecommunication
Nuclear PowerPlants
Automobiles
Boeing 777: Super Computers with Wings
Has
> 4M lines of code > 1K embedded processors
In order to
- control subsystems - aid pilots in flight mngmnt.
• interacts with humans in a sophisticated way.
A great challenge of software engineering:
• hard real-time deadlines,
• mission and safety-critical, • complex and embedded within another complex system,
Embedded Software Systems
• Difficult to develop & maintain:– Concurrent and distributed (OS, ES, middleware),
– Complicated by DS improving performance (locks, RC,...),
– Mostly written in C programming language.
• Have to be high-confidence: – Provide the critical infrastructure for all applications,
– Failures are very costly (business, reputation),
– Have to protect against cyber-attacks.
Temporal Properties
• Safety (something bad never happens):
- Airborne planes are at least 1 mile apart- Nuclear reactor core never overheats - Gamma knife never exceeds prescribed dose
• Liveness (something good eventually happens):
– Core eventually reaches nominal temperature– Dishwasher tank is eventually full– Airbag inflates within 5ms of collision
Linear Temporal Logic
• An LTL formula is made up of atomic propositions p, boolean connectives , , and temporal modalities X (neXt) and U (Until).
• Safety: “nothing bad ever happens” E.g. G( (pc1=cs pc2=cs)) where G is a derived
modality (Globally).
• Liveness: “something good eventually happens” E.g. G( req F serviced ) where F is a derived modality (Finally).
LTL Semantics
• Semantics given in terms of the inductively defined entailment relation ⊨ .
is an infinite word (execution) over the power set of the set of atomic propositions.
is an LTL formula.
LTL Semantics
X p :p
F p :p
p p p p U q :
qp p
p p pG p :
pp p
What is High-Confidence?
S |?
system-software S satisfies LTL property φ
Ability to guarantee that
Talk Outline
1. Embedded Software Systems
2. Automata-Theoretic Verification
3. Monte Carlo Verification
4. Monte Carlo Model Checking
5. Static Verification of Software-Systems
6. Dynamic Verification Software-Systems
Checking if
S |
• Statically (at compile time)
–Abstract interpretation (sequential IS programs),
–Model checking (concurrent FS programs),
• Dynamically (at run time)
– Runtime analysis (sequential program optimization).
• Basic Idea:
– Intelligently explore S’s state space in attempt to establish that S ⊨
Automata-Theoretic Approach
• Büchi automaton: NFA over -words with acceptance condition - a final state must be visited - often.
• Every LTL formula can be translated to a Büchi automaton B such that L() = L(B).
• State transition graph of S can also be viewed as a Büchi automaton.
Automata-theoretic approach
• Satisfaction reduced to language emptiness:
S ⊨ ≅ L(BS) L(B ) ≅ L(BS) ∩ L(B )
≅ L(BS) ∩ L(B ) ≅ L(BS B )
Büchi Automata
• Finite automata over infinite words.
1 2
• Checking non-emptiness is equivalent to finding a reachable accepting cycle (lasso).
ab
ab1 2
A B
L(A) = { ab } L(B) =
recurrencediameter
LassosComputation Tree (CT) of B
Explore all lassos in the CT
DDFS,SCC: time efficient DFS: memory efficient
Checking Non-Emptiness
Talk Outline
1. Embedded Software Systems
2. Automata-Theoretic Verification
3. Monte Carlo Verification
4. Monte Carlo Model Checking
5. Static Verification of Software-Systems
6. Dynamic Verification Software-Systems
Randomized Algorithms
• Huge impact on CS: (distributed) algorithms, complexity theory, cryptography, etc.
• Takes of next step algorithm may depend on random choice (coin flip).
• Benefits of randomization include simplicity, efficiency, and symmetry breaking.
Randomized Algorithms
• Monte Carlo: may produce incorrect result but with bounded error probability.
– Example: Election’s result prediction
• Las Vegas: always gives correct result but running time is a random variable.
– Example: Randomized Quick Sort
recurrencediameter
Explore N(,) independent lassos in the CT
Error margin and confidence ratio
Monte Carlo Approach
…
flip a k-sided coin
LassosComputation tree (CT) of B
Lassos Probability Space
• Sample Space: lassos in BS B
• Bernoulli random variable Z (coin flip):
– Outcome = 1 if randomly chosen lasso accepting
– Outcome = 0 otherwise
• pZ = ∑ pi Zi (expectation of an accepting lasso)
where pi is lasso prob. (uniform random walk)
Example: Lassos Probability Space
1
2
3
4
1
1 2
4 3
4 41
4
½
¼ ⅛
⅛
qZ = 7/8
pZ = 1/8
Geometric Random Variable
• Value of geometric RV X with parameter pz:
– No. of independent trials (lassos) until success
• Probability mass function:
– p(N) = P[X = N] = qzN-1 pz
• Cumulative Distribution Function:
– F(N) = P[X N] = ∑i Np(i) = 1 - qzN
How Many Lassos?
• Requiring 1 - qzN = 1- δ yields:
N = ln (δ) / ln (1- pz)
• Lower bound on number of trials N needed to achieve success with confidence ratio δ.
What If pz Unknown?
• Requiring pz ε yields:
M = ln (δ) / ln (1- ε) N = ln (δ) / ln (1- pz)
and therefore P[X M] 1- δ
• Lower bound on number of trials M needed to achieve success with
confidence ratio δ and error margin ε .
Statistical Hypothesis Testing
• Null hypothesis H0: pz ε
• Inequality becomes: P[ X M | H0 ] 1- δ
• If no success after N trials, i.e., X > M, then reject H0
• Type I error: α = P[ X > M | H0 ] < δ
Monte Carlo Verification (MV)
input: B=(Σ,Q,Q0,δ,F), ε, δ
N = ln (δ) / ln (1- ε)
for (i = 1; i N; i++)
if (RL(B) == 1) return (1, error-trace);
return (0, “reject H0 with α = Pr[ X > N | H0 ] < δ”);
RL(B): performs a uniform random walk through B storing states encountered in hash table to obtain a random sample (lasso).
Correctness of MV
Theorem: Given a Büchi automaton B, error margin ε, and confidence ratio δ, if MV rejects H0, then
its type I error has probability
α = P[ X > M | H0 ] < δ
Complexity of MV
Theorem: Given a Büchi automaton B having diameter D, error margin ε, and confidence ratio δ, MV runs in time O(N∙D) and uses space O(D), where N = ln(δ) / ln(1- ε)
Cf. DDFS which runs in O(2|S|+|φ|) time for B = BS B
Talk Outline
1. Embedded Software Systems
2. Automata-Theoretic Verification
3. Monte Carlo Verification
4. Monte Carlo Model Checking
5. Static Verification of Software-Systems
6. Dynamic Verification Software-Systems
Model Checking [ISOLA’04, TACAS’05]
• Implemented DDFS and MV in jMocha model checker for synchronous systems specified using Reactive Modules.
• Performance and scalability of MV compares very favorably to DDFS.
Dining Philosophers
DDFS MC2ph time entr time mxl cxl N
4 0.02 31 0.08 10 10 3 8 1.62 512 0.20 25 8 712 3:13 8191 0.25 37 11 1116 >20:0.0 - 0.57 55 8 1820 - oom 3.16 484 9 2030 - oom 35.4 1478 11 100
40 - oom 11:06 13486 10 209
(Deadlock freedom)
DPh: Symmetric Unfair Version
DDFS MC2ph time entr time mxl cxl N
4 0.17 29 0.02 8 8 2 8 0.71 77 0.01 7 7 112 1:08 125 0.02 9 9 116 7:47:0 173 0.11 18 18 120 - oom 0.08 14 14 130 - oom 1.12 223 223 1
40 - oom 1.23 218 218 1
(Starvation freedom)
DPh: Symmetric Unfair Version
DDFS MC2Phi time entries time max avg
4 0:01 178 0:20 49 216 0:03 1772 0:45 116 428 0:58 18244 2:42 365 99
10 16:44 192476 7:20 720 23412 - oom 21:20 1665 56414 - oom 1:09:52 2994 144216 - oom 3:03:40 7358 314418 - oom 6:41:30 13426 589620 - oom 19:02:00 34158 14923
DPh: Asymmetric Fair Version(Deadlock freedom)
δ = 10-1 ε = 1.8*10-3 N = 1278
DDFS MC2Phi time entries time max avg
4 0:01 538 0:20 50 216 0:17 9106 0:46 123 428 7:56 161764 2:17 276 97
10 - oom 7:37 760 24012 - oom 21:34 1682 57014 - oom 1:09:45 3001 136316 - oom 2:50:50 6124 298318 - oom 8:24:10 17962 739020 - oom 22:59:10 44559 17949
DPh: Asymmetric Fair Version (Starvation freedom)
δ = 10-1 ε = 1.8*10-3 N = 1278
Related Work
• Random walk testing: – Heimdahl et al: Lurch debugger
• Random walks to sample system state space:– Mihail & Papadimitriou (and others)
• Monte Carlo Model Checking of Markov Chains: – Herault et al: LTL-RP, bonded MC, zero/one ET
– Younes et al: Time-Bounded CSL, sequential analysis
– Sen et al: Time-Bounded CSL, zero/one ET
• Probabilistic Model Checking of Markov Chains:– ETMCC, PRISM, PIOAtool, and others.
Talk Outline
1. Embedded Software Systems
2. Automata-Theoretic Verification
3. Monte Carlo Verification
4. Monte Carlo Model Checking
5. Static Verification of Software-Systems
6. Dynamic Verification Software-Systems
Checking for High-Confidence(in-principle)
Instrumenter(Product)
BA BS
ExecutionEngine
LTL-P
BA
BS B
All LassosNon-accepting
AcceptingLasso L
• Combine static & runtime verification techniques:– Abstract interpretation (sequential IS programs),
– Model checking (concurrent FS programs),
– Runtime analysis (sequential program optimization).
• Make scalability a priority: – Open source compiler technology started to mature,
– Apply techniques to source code rather than models,• Models can be obtained by abstraction-refinement techniques,
– Probabilistic techniques trade-of between precision-effort.
Checking for High-Confidence(in-practice)
GCC Compiler
• Early stages: a modest C compiler.- Translation: source code translated directly to RTL.
- Optimization: at low RTL level.
- High level information lost: calls, structures, fields, etc.
• Now days: full blown, multi-language compiler generating code for more than 30 architectures.
- Input: C, C++, Objective-C, Fortran, Java and Ada.
- Tree-SSA: added GENERIC, GIMPLE and SSA ILs.
- Optimization: at GENERIC, GIMPLE, SSA and RTL levels.
- Verification: Tree-SSA API suitable for verification, too.
GCC Compilation Process
Java FileC++ FileC File
C Parser
C++ Parser
Java Parser
Genericize
Gimplify
Parse Tree
GEN AST
..
GPL AST
Code Gen
Build CFG
GPL AST
Rest Comp
SSA/GPL CFG
RTL Code
Obj Code
GCC Compilation Process
Java FileC++ FileC File
C Parser
C++ Parser
Java Parser
Genericize
Gimplify
Parse Tree
GEN AST
..
GPL AST
Code Gen
Build CFG
GPL AST
Rest Comp
SSA/GPL CFG
RTL Code
Obj Code
APIPlug-In
C Program and its GIMPLE IL
int main() {
int a,b,c;
a = 5;
b = a + 10;
c = a + foo(a,b);
if (a > c)
c = b++/a + b*a;
bar(a,b,c); }
int main {
int a,b,c; int T1,T2,T3,T4;
a = 5; b = a + 10; T1 = foo(a,b); T2 = a + T1;
if (a > T2) goto fi; T3 = b / a; T4 = b * a; c = T2 + T3; b = b + 1;fi: bar(a,b,c); }
Gimplify
Associated GIMPLE CFG
a = 5;b = a + 10;T1 = foo(a,b);T2 = b + T1;if (a > T2) goto B;
A
a 5
=CE
b
a 10
+
=
CE
CE
b
T1
foo a
CallE
= B
a T2
>
if
CE
T2
b T1
+
=T3 = b / a;T4 = b * a;c = T3 + T4;b = b + 1;
bar(a,b,c);return;
Exit
true falseBC
FUNCTION DECL
Entry int int int int int int inta T4T3T2c T1b
MC Static Verification of ESS[SOFTMC’05, NGS’06]
Gimplify
SS S
InstrumentLTL-P
CFG BS
GCC
CFG
BS B
VerifierGAM static
Monte Carlo Algorithm
• Input: a set of CFGs.– Main function: A specifically designated CFG.
• Random walks in the Büchi automaton: generated on-the-fly.– Initial state: of the main routine + bookkeeping information.
– Next state: choose process + call GAM on its CFG.
– Processes: created by using the fork primitive.
– Optimization: GAM returns only upon context switch.
• Lassos: detected by using a hierarchic hash table.– Local variables: removed upon return from a procedure.
Shared Variables Valuation(channels & semaphores)
List Of Process statesp1 p2 p3 …
CFG Name Statement #
Control State Data State
Program State
Shared Variables Valuation(channels & semaphores)
List Of Process statesp1 p2 p3 …
Heap Global Variables Valuation
Control State Data State
Frame Stack
Return Control State Local Variables Valuation
f1 f2 …
Program State
GIMPLE Abstract Machine (GAM)
• Interprets GIMPLE statements: according to their semantics. Interesting:– Inter-procedural: call(), return(). Manipulate the frame
stack.
• Catches and interprets: function calls to various modeling and concurrency primitives:– Modeling: toss(), assert(). Nondeterminism and checks.
– Processes: fork(), … Manipulate the process list.
– Communication: send(), recv(). Manipulate shared vars. May involve a context switch.
GMVproperty rule bugs time sampl
1 no 0.23 1278 Safe Advisory Selection 2 yes 0.03 147
1 no 0.23 1278 Best Advisory Selection 2 yes 0.04 206
1 yes 0.01 36 Avoid unnecessary Crossing 2 yes 0.03 180
1 yes 0.01 27No. Crossing Adv. Selection 2 yes 0.01 8
1 no 0.23 1278Optimal Advisory Selection 2 yes 0.06 217
Results: TCAS
GMV Verisoftph time sampl ce.len time states trans
4 0:00.07 2 12 0:00.61 16 37 6 0:00.11 4 12 0:16.60 773 11718 0:00.78 11 20 2:57.29 5431 8449 10 0:02.17 31 24 10:41 17908 31433 12 0:04.82 24 27 >2hr N/A N/A 14 0:06.22 22 44 >2hr N/A N/A
16 0:11.56 14 32 >2hr N/A N/A
(Deadlock freedom)
DPh: Symmetric Fair Version
GMV Verisoft Genetic time sampl time states time errors
6h 37' 10,682,639 >8h N/A 2h 33' 3
Needham-Schroeder Protocol
• Quite sophisticated C implementation.
• However, of a sequential nature:- Essentially executes only one round of a reactive system
Related Work
• Software model checkers for concurrent C/C++: – VeriSoft, Spin, Blast (Slam), Magic, C-Wolf. Bogor?
• Cooperative Bug Isolation [Liblit, Naik & Zheng]:– Compile-time instrumentation. Distribute binaries/collect bugs.
– Statistical analysis to isolate erroneous code segments.
• Random interpretation [Gulvany & Necula]: – Execute random paths and merge with random linear operators.
• Monte Carlo and abstract interpretation [Monniaux]: – Analyze programs with probabilistic and nondeterministic input.
Talk Outline
1. Embedded Software Systems
2. Automata-Theoretic Verification
3. Monte Carlo Verification
4. Monte Carlo Model Checking
5. Static Verification of Software-Systems
6. Dynamic Verification Software-Systems
MC Runtime Verification of ESS[MBT’06, NGS’06]
Gimplify
SS S
InstrumentLTL-P
CFG BS
GCC
CFG
BS B
VerifierGAM static
Rst-CompGCC
Linker DispatcherHWMruntime
Runtime Verification Challenges
• Inserting instrumentation code
• Verifying states and transitions
• Reducing overheads
Inserting Instrumentation Code
struct inode* my_inode;atomic_t my_atomic;
my_atomic = my_inode->i_count;
if(instrument) log_event(ATOMIC_INC, INODE, my_atomic);
atomic_inc(my_atomic);
Instrumentation Plug-Ins
• Ref-Counts: detects misuse of reference counts– Instruments: inc(rc), dec(rc),– Checks: st-inv (rc0), tr-inv (|rc′-rc|=1), leak-inv (rc>0 ~> rc=0), – Maintains: a list of reference counts and their container type.
• Malloc: detects allocation bugs at runtime– Instruments: malloc() and free() function calls,– Checks sequences: free()free(), $free() and malloc()$,– Maintains: a list of existing allocations.
• Bounds: checks for invalid memory access– Instruments: malloc(), free() and f(a),– Checks: accesses to non-allocated areas,– Maintains: heap, stack and text allocations– Higher accuracy than ElectricFence-like libraries.
Instrumentation Plug-Ins
• Lasso concept weakened (abstracted):
- Execution where: RC vary 0 ↗ … ↘ 0
- State: may include FS caches, HW regs, etc
• Lasso sampling used to reduce overhead:
- Check: for acceptance (error)
- Dynamically adjust: sampling rate
RC Runtime Verification
Sampling Granularity
Accesses
Refe
ren
ce c
ou
nt
Sample
State and Transition Invariants
Accesses
Refe
ren
ce c
ou
nt
Change >1
Change <1
Value <0
The Leak Invariant
Time
Refe
ren
ce c
ou
nt
Timeout
Timeout
Proof of Concept
• Check Linux file system cache objects
– inodes: on-disk files
– dentries: name-space nodes
• Optionally, log all events
• Simple per-category sampling policy
– Initially: sample all objects
– Hypothesize: err. rate ε > 10-5 and con. ratio δ = 10-5
– Stop sampling: if hypothesis is false.
Benchmarks
• Directory traversal benchmark
– Create a directory tree (depth 5, degree 6)– Traverse the tree– Recursively delete the tree
• Also tested GNU tar compilation
• Testbed:
– 1.7GHz Pentium 4 (256Kb cache)
– 1Gbyte RAM
– Linux 2.6.10
Results
0
20
40
60
80
100
120
0 5 10 15 20 25
Tim
e (
se
co
nd
s)
Run number
Logging: ~10x
~3x
1,33x
Results
0
20
40
60
80
100
120
0 5 10 15 20 25
Tim
e (
se
co
nd
s)
Run number
Checking: ~2x
1,33x1,1x
Sampling-Policy Automata
• Specify how to respond to events
– Violating trajectories
– Invalidations of violation rate estimates
• Control trajectory sampling rate
• A simple SPA:
cs = n cs = n+1
ε > pz
Related Work: SWAT
• Chilimbi & Hauswirth: – Low-Overhead Memory Leak Detection Using Adaptive
Statistical Profiling
• Instrument heap accesses
• Block-level dynamic instrumentation
• Reduce instrumentation based on number of times a block has been hit
• No formal measure of confidence provided
Conclusions
• GSRV is a novel tool suite for randomized: – Static and runtime verification of ESS (growing)
• General purpose tools (plug-ins):– Code instrumenter: constructs the product BA
– Intra/inter-procedural slicer: in work
• Static verification tools (plug-ins):– GAM: CFG-GIMPLE abstract machine
– Monte Carlo MC: statistical algorithm for LTL-MC
• Runtime verification tools (static libraries):– Dispatcher: catches and dispatches events to RV
– Monte Carlo RV: statistical algorithm for LTL-RV