1. Model Checking and Its Applications
Orna Grumberg
Technion, Israel
Lecture 2
Summer School of Formal Techniques (SSFM) 2019

2. Outline Model checking of finite-state systems
Assisting in program development
Program repair
Program differencing

3. Anna Trostanetski, Orna Grumberg, Daniel Kroening (SAS 2017)
Modular Demand-Driven Analysis of Semantic Difference for Program Versions
Anna Trostanetski, Orna Grumberg, Daniel Kroening
(SAS 2017)

4. Program versions
Programs often change and evolve, raising the following interesting questions:
Did the new version introduce new bugs or security vulnerabilities?
Did the new version remove bugs or security vulnerabilities?
More generally, how does the behavior of the program change?

5. Differences between program versions can be exploited for:
Regression testing of new version w.r.t. old version, used as “golden model”
Producing zero-day attacks on old version
characterizing changes in the program’s functionality

6. What is a difference in behavior?
void p1(int& x) {
if (x < 0)
x = -1;
return;
x--;
if (x >= 1)
x=x+1;
else
while ( x ==1);
x=0; }
void p2(int& x) {
if (x < 0)
x = -1;
return;
x--;
if (x > 2)
x=x+1;
else
while ( x == 1);
x=0; }

7. Full difference summary

8. Full difference summary
violate Partial Equivalence

9. Full difference summary

10. Full difference summary
violate Mutual Termination

11. Full difference summary

12. Full difference summary
Full Equivalence

13. Full difference summary

14. Example void p1(int& x) { if (x < 0) x = -1; return; x--;
Example
void p1(int& x) {
if (x < 0)
x = -1;
return;
x--;
if (x >= 1)
x=x+1;
else
while ( x ==1);
x=0; }
void p2(int& x) {
if (x < 0)
x = -1;
return;
x--;
if (x > 2)
x=x+1;
else
while ( x == 1);
x=0; }

15. Difference Summary - computation

16. Difference Summary - computation
Input space

17. Difference Summary - computation?

18. Difference Summary - computation?
Under approxi-mation

19. Difference Summary - computation?
Over
approximation

20. main goal

21. How Programs Change call graphs
Changes are small, programs are big
Can our work be O(change) instead of O(program)?

22. Which procedures could be affected
potential semantical change
syntactical change

23. Which procedures are affected
semantical change

24. Main ideas (1)
Modular analysis applied to one pair of procedures at a time
No inlining
Only affected procedures are analyzed
Over- and under-approximation of difference between procedures are computed

25. Main ideas (2) Procedures need not be fully analyzed:
Unanalyzed parts are abstraction using uninterpreted functions
Refinement is applied upon demand
Anytime analysis:
Not necessarily terminates
Its partial results are meaningful
The longer it runs, the more precise its results are

26. Program representation
Program is represented by a call graph
Every procedure is represented by a Control Flow Graph (CFG)
We are also given a matching function between procedures in the old and new versions

27. A call graph is a directed graph:
Nodes represent procedures
It contains edge p  q if procedure p includes a call for procedure q
A control flow graph (CFG) is a directed graph:
Nodes represent program instructions (assignments, conditions and procedure calls)
Edges represent possible flow of control

28. We start by characterizing a single finite path in a single procedure

29. example F T

30. example F T

31. Example R(x,y) = x  0  x-1  1 T(x,y) = (x-1,x) y = x+1 T x < 0F T
x := x-1
x == 1
R(x,y) =
x  0  x-1  1
T(x,y) = (x-1,x)

32. Path characterization

33. Procedure summary

34. example
x=0
x >= 1
x = -1
x=x+1
x < 0 F T
x := x-1
x == 1

35. From summary to difference summary

36. example T T x < 0 x < 0 x := x-1 return -1 x := x-1 x=-1 F F

37. example T T x < 0 x < 0 x := x-1 return -1 x := x-1 x=-1 F F

38. example T T x < 0 x < 0 x := x-1 return -1 x := x-1 x=-1 F F

39. Symbolic execution Input variables are given symbolic values
Every execution path is explored individually (in some heuristic order)
On every branch, a feasibility check is performed with a constraint solver
For procedure p the input variables are the parameters of p, denoted Vp

40. Computing symbolic execution

41. Computing symbolic execution

42. symbolic execution

43. computing the summaries
To compute path summaries without in-lining called procedures We suggest modular symbolic execution

44. Modular symbolic execution

45. Modular symbolic execution

46. Modular symbolic execution

47. Can we do better?
Use abstraction for the un-analyzed (uncovered) parts
Later check if these parts are needed at all for the analysis of calling procedure
If needed - refine

48. Abstraction

49. Abstract modular symbolic execution

50. Refinement
Since we are using uninterpreted functions, the discovered difference may not be feasible:
void p1(int& x) {
if (x == 5) {
abs1(x);
if (x==0)
x = 1; }
void p2(int& x) {
if (x == 5) {
abs2(x);
if (x==0)
x = -1; }
abs1=abs2=abs

51. Refinement

52. Refinement

53. overall algorithm
Start the analysis from the syntactically changed procedures. Analyze them with modular symbolic execution up to a certain bound
Compute difference summaries for those procedures, if you can prove equivalence for all inputs – stop.
Use refinement when needed
Repeat for calling procedures
Can be guided towards interesting procedures by the user

54. Experimental Results – Equivalent Benchmarks
We compared to two tools that prove equivalence between procedures:
Regression Verification Tool (RVT)
Godlin, Benny, and Ofer Strichman. "Regression verification." Proceedings of the 46th Annual Design Automation Conference. ACM, 2009.
SymDiff
Lahiri, Shuvendu K., et al. "SYMDIFF: A Language-Agnostic Semantic Diff Tool for Imperative Programs." CAV. Vol

55. Experimental Results – Equivalent Benchmarks
MDDiff
MDDiffRef
RVT
SymDiff
Const
0.545s
0.541s
4.06s
14.562s
Add
0.213s
0.2s
3.85s
14.549s
Sub
0.258s
0.308s
5.01s F
Comp
0.841s
0.539s
5.19s
LoopSub
0.847s
1.179s
UnchLoop
2.838s
LoopMult2
1.666s
1.689s
LoopMult5
3.88s
LoopMult10
9.543s
LoopMult15
21.55s
LoopMult20
49.031s
LoopUnrch2
0.9s
0.941s
LoopUnrch5
1.131s
1.126s
LoopUnrch10
1.147s
1.168s
LoopUnrch15
1.132s
1.191s
LoopUnrch20
1.157s
1.215s

56. Experimental Results – Equivalent Benchmarks
MDDiff
MDDiffRef
RVT
SymDiff
Const
0.545s
0.541s
4.06s
14.562s
Add
0.213s
0.2s
3.85s
14.549s
Sub
0.258s
0.308s
5.01s F
Comp
0.841s
0.539s
5.19s
LoopSub
0.847s
1.179s
UnchLoop
2.838s
LoopMult2
1.666s
1.689s
LoopMult5
3.88s
LoopMult10
9.543s
LoopMult15
21.55s
LoopMult20
49.031s
LoopUnrch2
0.9s
0.941s
LoopUnrch5
1.131s
1.126s
LoopUnrch10
1.147s
1.168s
LoopUnrch15
1.132s
1.191s
LoopUnrch20
1.157s
1.215s

57. Experimental Results – Equivalent Benchmarks
MDDiff
MDDiffRef
RVT
SymDiff
Const
0.545s
0.541s
4.06s
14.562s
Add
0.213s
0.2s
3.85s
14.549s
Sub
0.258s
0.308s
5.01s F
Comp
0.841s
0.539s
5.19s
LoopSub
0.847s
1.179s
UnchLoop
2.838s
LoopMult2
1.666s
1.689s
LoopMult5
3.88s
LoopMult10
9.543s
LoopMult15
21.55s
LoopMult20
49.031s
LoopUnrch2
0.9s
0.941s
LoopUnrch5
1.131s
1.126s
LoopUnrch10
1.147s
1.168s
LoopUnrch15
1.132s
1.191s
LoopUnrch20
1.157s
1.215s

58. summary We have presented a difference analysis method that is:
Modular (analyzes each procedure independently of its current use)
Computes over- and under-approximation of inputs that produce different behavior
Introduces abstraction in the form of uninterpreted functions, and allows refinement upon demand

59. Evolving software

60. Thank you