Presentation is loading. Please wait.

Presentation is loading. Please wait.

Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 1: Introduction Roman Manevich Ben-Gurion University.

Similar presentations


Presentation on theme: "Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 1: Introduction Roman Manevich Ben-Gurion University."— Presentation transcript:

1 Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 1: Introduction Roman Manevich Ben-Gurion University

2 Agenda Motivation Approaches to software reliability Course overview 2

3 The need for reasoning about software systems 3

4 December 31, 2008 30GB Zunes all over the world fail en masse 4

5 What happens when days=366? Zune bug 1 while (days > 365) { 2 if (IsLeapYear(year)) { 3 if (days > 366) { 4 days -= 366; 5 year += 1; 6 } 7 } else { 8 days -= 365; 9 year += 1; 10 } 11 } 5 Suggested solution: wait for tomorrow

6 Fixed code while (days > 365) { if (IsLeapYear(year)) { if (days > 366) { days -= 366; year += 1; } else { break; } } else { days -= 365; year += 1; } 6

7 Fixed code – specify termination [ true ] while (days > 365) { if (IsLeapYear(year)) { if (days > 366) { days -= 366; year += 1; } else { break; } } else { days -= 365; year += 1; } [ true ] 7 For all inputs Must reach here

8 Fixed code – manual termination proof [ true ] Variant = [ t=days ] while (days > 365) { [ days  0  k=days  days>365 ] if (IsLeapYear(year)) { [ k=days  days>365 ] if (days > 366) { [ k=days  days>365] days -= 366; [ days=k-366  days>0 ] year += 1; [ days=k-366  days>0 ] } else { [ k=days  days>365  days  366 ] break; [ false ] } [ days 0 ] } else { [ k=days  days>365 ] days -= 365; [ 0  days<k ] year += 1; [ days<k  days  0 ] } [ days<k  days  0 ] } [ true ] 8

9 August 13, 2003 Billy Gates why do you make this possible ? Stop making money and fix your software!! (W32.Blaster.Worm) 9

10 Windows exploit(s) Buffer Overflow 10 void foo (char *x) { char buf[2]; strcpy(buf, x); } int main (int argc, char *argv[]) { foo(argv[1]); }./a.out abracadabra Segmentation fault Stack grows this way Memory addresses Previous frame Return address Saved FP char* x buf[2] … ab ra ca da br

11 Buffer overrun exploits int check_authentication(char *password) { int auth_flag = 0; char password_buffer[16]; strcpy(password_buffer, password); if(strcmp(password_buffer, "brillig") == 0) auth_flag = 1; if(strcmp(password_buffer, "outgrabe") == 0) auth_flag = 1; return auth_flag; } int main(int argc, char *argv[]) { if(check_authentication(argv[1])) { printf("\n-=-=-=-=-=-=-=-=-=-=-=-=-=-\n"); printf(" Access Granted.\n"); printf("-=-=-=-=-=-=-=-=-=-=-=-=-=-\n");} else printf("\nAccess Denied.\n"); } (source: “hacking – the art of exploitation, 2 nd Ed”) 11 Warning: unguarded access to array

12 Shellshock 12

13 Device drivers 13

14 Driver’s Source Code in C Precise API Usage Rules (SLIC) Defects 100% path coverage Rules Static Driver Verifier Environment model Static Driver Verifier 14

15 Bill Gates’ Quote "Things like even software verification, this has been the Holy Grail of computer science for many decades but now in some very key areas, for example, driver verification we’re building tools that can do actual proof about the software and how it works in order to guarantee the reliability." Bill Gates, April 18, 2002. Keynote address at WinHec 2002 Keynote addressWinHec 2002 15

16 Approaching software reliability 16

17 Testing is not enough Observe some program behaviors What can you say about other behaviors? Concurrency makes things worse Smart testing is useful – Driven by static analysis techniques 17

18 Static analysis definition Reason statically (at compile time) about the possible runtime behaviors of a program “The algorithmic discovery of properties of a program by inspection of its source text 1 ” -- Manna, Pnueli 1 Does not have to literally be the source text, just means w/o running it 18

19 The gist of Static analysis 19

20 Goal: exploring program states initial states bad states 20 reachable states Problem: cannot cover all reachable states in finite time

21 universe Central idea: use approximation Under Approximation Exact set of configurations/ behaviors 21 Over Approximation

22 Technique: explore abstract states initial states bad states 22 reachable states

23 Technique: explore abstract states initial states bad states 23 reachable states

24 Technique: explore abstract states initial states bad states 24 reachable states

25 Technique: explore abstract states initial states bad states 25 reachable states

26 Sound: cover all reachable states 26 initial states bad states reachable states

27 Unsound: miss some reachable states 27 initial states bad states reachable states

28 Imprecise abstraction initial states bad states 28 reachable states False alarms

29 Runtime vs. static analysis RuntimeStatic analysis EffectivenessCan miss errors Finds real errors Can find rare errors Can raise false alarms CostProportional to program’s execution Proportional to program’s complexity No need to efficiently handle rare cases Can handle limited classes of programs and still be useful 29

30 About this course 30

31 A little about me History – Studied B.Sc., M.Sc., Ph.D. at Tel-Aviv University Research in program analysis with IBM and Microsoft – Post-doc in UCLA and in UT Austin Research in program analysis and synthesis – Joined Ben-Gurion University on 2012 31

32 32

33 Why study program analysis? Learn how to use abstraction to deal with intractable (usually undecidable) problems Understand how to systematically – Design compiler optimizations – Reason about correctness / find bugs (security) Some techniques may be applied in other domains – Computational learning – Analysis of biological systems 33

34 What do you get in this course? Learn basic principles of static analysis – Understand jargon/papers Obtain some experience via assignments Put to practice what you learned in logic, automata, data structures, and programming 34

35 My role Teach you theory and practice Teach you how to think of new techniques Course web-pageweb-page – Announcements – Forum – Slides + lecture recordings Office hours: Wednesday 12:00-14:00 E-mail: romanm@cs.bgu.ac.ilromanm@cs.bgu.ac.il Skype: rmanevich 35

36 Requirements 1.50%: 3-4 theoretical assignments and programming assignments – Must obtain passing grade for each 2.50%: Exam – Must obtain passing grade 36

37 How to succeed in this course Attend class – Make sure you understand material at class – Solve worksheets – Engage by asking questions and raising ideas Be on top of assignments – Submit on time – Don’t get stuck or give up on exercises – get help – ask me – Don’t start working on assignments the day before Be ethical Joe (a day before assignment deadline): “I don’t really understand what you want from me in this assignment, can you help me/extend the deadline”? 37

38 Tentative syllabus Semantics Natural Semantics Structural semantics Axiomatic Verification Static Analysis Automating Hoare Logic Control Flow Graphs Equation Systems Collecting Semantics Abstract Interpretation fundamentals LatticesFixed-Points Chaotic Iteration Galois Connections Domain constructors Widening/ Narrowing Analysis Techniques Numerical Domains Alias analysis Interprocedural Analysis Shape Analysis CEGAR Crafting your own Soot From proofs to abstractions Systematically developing transformers 38

39 Next lecture: operational semantics of programming languages 39


Download ppt "Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 1: Introduction Roman Manevich Ben-Gurion University."

Similar presentations


Ads by Google