Model Checking and Its Applications

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. Modular Demand-Driven Analysis of Semantic Differencefor 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; return; else while ( x ==1); x=0; } void p2(int& x) { if (x < 0) x = -1; return; x--; if (x > 2) x=x+1; return; 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--; if (x >= 1) x=x+1; return; else while ( x ==1); x=0; } void p2(int& x) { if (x < 0) x = -1; return; x--; if (x > 2) x=x+1; return; 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 edgep  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 T F T F

30. example F T T F T F

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

32. Path characterization

33. Procedure summary

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

35. From summary to difference summary

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

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

38. example T T F F x >= 1 x > 2 x == 1 x == 1 x=x+1 x=x+1 x < 0 x < 0 x=0 x=x+1 return -1 x=-1 x := x-1 x := x-1 T T F F T T 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 proceduresWe 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 p2(int& x) { if (x == 5) { abs2(x); if (x==0) x = -1; } } void p1(int& x) { if (x == 5) { abs1(x); if (x==0) x = 1; } } abs1=abs2=abs