SOFTWARE VERIFICATION AND ABSTRACT INTERPRETATION Orna Grumberg and - - PowerPoint PPT Presentation

▶
software verification and abstract interpretation
SMART_READER_LITE
LIVE PREVIEW

SOFTWARE VERIFICATION AND ABSTRACT INTERPRETATION Orna Grumberg and - - PowerPoint PPT Presentation

Sep 02, 2023 343 likes •901 views

Lecture 01 - Introduction SOFTWARE VERIFICATION AND ABSTRACT INTERPRETATION Orna Grumberg and EranYahav Slides based on the PPA book by Nielson, Nielon and Hankin, on some slides from Mooly Sagiv, some slides from Patrick Cousot and on lecture

slide-1
SLIDE 1

SOFTWARE VERIFICATION AND ABSTRACT INTERPRETATION

Lecture 01 - Introduction

Orna Grumberg and EranYahav

1

Slides based on the PPA book by Nielson, Nielon and Hankin,

  • n some slides from Mooly Sagiv, some slides from Patrick Cousot

and on lecture notes by Xavier Rival

slide-2
SLIDE 2

Goal

  • What will help us

 lecture summaries  3-5 homework assignments  Small lightweight project

  • Will also help

 Taking a deep breath  Focusing on material and not on

your grade

  • Understand software verification with abstract interpretation

2

slide-3
SLIDE 3

Schedule

  • Tue (March 2) 12:30-14:30
  • Thu (March 4) 10:30-12:30
  • Tue (March 9) 12:30-14:30
  • Thu (March 11) 10:30-12:30
  • Sun (March 14) 16:30-18:30
  • Tue (March 16) 12:30-14:30
  • Tue (March 23) 12:30-14:30

 Guest lecture by Dr. Noam Rinetzky

  • Passover break
  • Every Tuesday 12:30-14:30 – Orna

Eran

3

slide-4
SLIDE 4

Why Study Software Verification?

  • More critical software
  • More complicated software
  • Bigger software
  • Security and privacy risks
  • Lightweight verification is economically

justified

4

slide-5
SLIDE 5

Why Study Software Verification?

5

slide-6
SLIDE 6

Slope of Enlightenment

  • Lower expectations for automation
  • Lower expectations of properties to be

verified

  • Lower expectations for user specifications
  • Weaker guarantees

 Bounded “verification”  Smart testing  …

6

slide-7
SLIDE 7

December 31, 2008

7

slide-8
SLIDE 8

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 }

8

slide-9
SLIDE 9

Zune Bug

1 while (366 > 365) { 2 if (IsLeapYear(2008)) { 3 if (366 > 366) { 4 days -= 366; 5 year += 1; 6 } 7 } else { 8 days -= 365; 9 year += 1; 10 } 11 }

Suggested solution: wait for tomorrow

9

slide-10
SLIDE 10

February 25, 1991

10

slide-11
SLIDE 11

Patriot Bug - Rounding Error

  • Time measured in 1/10 seconds
  • Binary expansion of 1/10:

0.0001100110011001100110011001100....

  • 24-bit register

0.00011001100110011001100

  • error of

 0.0000000000000000000000011001100... binary, or

~0.000000095 decimal

  • After 100 hours of operation error is

0.000000095×100×3600×10=0.34

  • A Scud travels at about 1,676 meters per second, and

so travels more than half a kilometer in this time

Suggested solution: reboot every 10 hours

11

slide-12
SLIDE 12

August 13, 2003 I just want to say LOVE YOU SAN!!

(W32.Blaster.Worm)

12

slide-13
SLIDE 13

Windows Exploit(s)

Buffer Overflow

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 (YMMV)

13

slide-14
SLIDE 14

Resource Leaks

class ListView extends ... { private Image imgView = null; // ... protected void handleResize(boolean bForce) { // ... if (imgView == null || bForce) { imgView = new Image(listCanvas.getDisplay(), clientArea); lastBounds = new Rectangle(0, 0, 0, 0); bNeedsRefresh = true; } else { // ... } // ... } }

imgView OS Resources OS Resources (real code from Azureus P2P client)

14

slide-15
SLIDE 15

(In)correct Usage of APIs

  • Application Trend: Increasing number of libraries and APIs

– Non-trivial restrictions on permitted sequences of operations

  • Typestate:Temporal safety properties

– What sequence of operations are permitted on an object? – Encoded as DFA e.g. “Don’t use a Socket unless it is connected” init connected closed err

connect() close() getInputStream() getOutputStream() getInputStream() getOutputStream() getInputStream() getOutputStream() close()

*

15

slide-16
SLIDE 16

Challenges

class SocketHolder { Socket s; } Socket makeSocket() { return new Socket(); // A }

  • pen(Socket l) {

l.connect(); } talk(Socket s) { s.getOutputStream()).write(“hello”); } main() { Set<SocketHolder> set = new HashSet<SocketHolder>(); while(…) { SocketHolder h = new SocketHolder(); h.s = makeSocket(); set.add(h) } for (Iterator<SocketHolder> it = set.iterator(); …) { Socket g = it.next().s;

  • pen(g);

talk(g); } }

I’m skeptical

16

slide-17
SLIDE 17

Testing is Not Enough

  • Observe some program behaviors
  • What can you say about other behaviors?
  • Concurrency makes things worse
  • Smart testing can be useful

 requires the techniques that we will see in the

course

17

slide-18
SLIDE 18

Static Analysis

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 text1”

  • - Manna, Pnueli

1 Does not have to literally be the source text, just means w/o running it

18

slide-19
SLIDE 19

Static Analysis

x = ? if (x > 0) { y = 42; } else { y = 73; foo(); } assert (y == 42);

  • Bad news: problem is generally undecidable

19

slide-20
SLIDE 20

universe

Static Analysis

  • Central idea: use approximation

Under Approximation Exact set of configurations/ behaviors Over Approximation

20

slide-21
SLIDE 21

Over Approximation

x = ? if (x > 0) { y = 42; } else { y = 73; foo(); } assert (y == 42);

  • Over approximation: assertion may be violated

21

slide-22
SLIDE 22
  • Lose precision only when required
  • Understand where precision is lost

Precision

main(…) { printf(“assertion may be vioalted\n”); }

22

slide-23
SLIDE 23

Static Analysis

  • Formalize software behavior in a

mathematical model (semantics)

  • Prove properties of the mathematical model

 Automatically, typically with approximation of the

formal semantics

  • Develop theory and tools for program

correctness and robustness

23

slide-24
SLIDE 24

Static Analysis

  • Spans a wide range from type checking to full

verification

  • General safety specifications
  • Security properties (e.g., information flow)
  • Concurrency correctness conditions (e.g.,

progress, linearizability)

  • Correct use of libraries (e.g., typestate)
  • Under-approximations useful for bug-finding,

test-case generation,…

24

slide-25
SLIDE 25

Static Analysis: Techniques

  • Dataflow analysis
  • Constraint-based analysis
  • Type and effect systems
  • …

Abstract Interpretation

25

slide-26
SLIDE 26

Verification Challenge I

main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y } Determine what states can arise during any execution

Challenge: set of states is unbounded

26

slide-27
SLIDE 27

Abstract Interpretation

main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y }

Recipe

1) Abstraction 2) Transformers 3) Exploration

Challenge: set of states is unbounded Solution: compute a bounded representation

  • f (a superset) of program states

Determine what states can arise during any execution

27

slide-28
SLIDE 28

1) Abstraction

main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y }

  • concrete state
  • abstract state

: Var Z #: Var{+, 0, -, ?}

x y i 3 1

7

x y i + +

+

3 2

6

x y i

…

28

slide-29
SLIDE 29

2) Transformers

main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y }

  • concrete transformer
  • abstract transformer

x y i + + x y i 3 1

y = y + 1

x y i 3 2 x y i + +

y = y + 1

+ - + ? + + + + ? + ?

29

slide-30
SLIDE 30

3) Exploration

+ +

?

+ +

?

x y i

main(int i) { int x=3,y=1; do { y = y + 1; } while(--i > 0) assert 0 < x + y }

+ +

?

+ +

?

? ?

?

x y i + +

?

+ +

?

+ +

?

+ +

?

+ +

?

+ +

?

30

slide-31
SLIDE 31

Incompleteness

main(int i) { int x=3,y=1; do { y = y - 2; y = y + 3; } while(--i > 0) assert 0 < x + y }

+ ?

?

+ ?

?

x y i + ?

?

+ +

?

? ?

?

x y i + ?

?

+ ?

?

+ ?

?

31

slide-32
SLIDE 32

Verification Challenge II: Stack init

t x n x t n x t n n x t n n x t t x n t t n t x t x t x emp

void init(int i) { Node* x = null; do { Node t = malloc(…) t->n = x; x = t; } while(--i>0) Top = x; }

assert(acyclic(Top))

t x n n x t n n x t n n n x t n n n x t n n n top

32

slide-33
SLIDE 33

Following the Recipe (In a Nutshell)

1) Abstraction

Concrete state Abstract state

x t n n n x t n

2) Transformers

n x t n t n x n

t->n = x

33

slide-34
SLIDE 34

x t n n t x n x t n x t n n x t t x n t t n t x t x t x emp x t n n x t n n n x t n t n x n x t n n

3) Exploration

void init(int i) { Node* x = null; do { Node t = malloc(…) t->n = x; x = t; } while(--i>0) Top = x; }

assert(acyclic(Top))

x t n Top n n t x Top t x Top x t n Top n

34

slide-35
SLIDE 35

Challenge III

proc MC(n:int) returns (r:int) var t1:int, t2:int; begin if (n>100) then r = n-10; else t1 = n + 11; t2 = MC(t1); r = MC(t2); endif; end var a:int, b:int; begin b = MC(a); end

What is the result of this program?

35

slide-36
SLIDE 36

McCarthy 91 function

proc MC (n : int) returns (r : int) var t1 : int, t2 : int; begin /* (L6 C5) top */ if n > 100 then /* (L7 C17) [|n-101>=0|] */ r = n - 10; /* (L8 C14) [|-n+r+10=0; n-101>=0|] */ else /* (L9 C6) [|-n+100>=0|] */ t1 = n + 11; /* (L10 C17) [|-n+t1-11=0; -n+100>=0|] */ t2 = MC(t1); /* (L11 C17) [|-n+t1-11=0; -n+100>=0;

  • n+t2-1>=0; t2-91>=0|] */

r = MC(t2); /* (L12 C16) [|-n+t1-11=0; -n+100>=0;

  • n+t2-1>=0; t2-91>=0; r-t2+10>=0;

r-91>=0|] */ endif; /* (L13 C8) [|-n+r+10>=0; r-91>=0|] */ end var a : int, b : int; begin /* (L18 C5) top */ b = MC(a); /* (L19 C12) [|-a+b+10>=0; b-91>=0|] */ end

if (n>=101) then n-10 else 91

36

slide-37
SLIDE 37

How Does it Work?

37

slide-38
SLIDE 38

Dataflow Analysis

  • Reaching Definitions

 The assignment lab: var := exp reaches lab’ if there is

an execution where var was last assigned at lab

1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y − 1 } 6: y := 0

(adapted from Nielson, Nielson & Hankin) { (x,?), (y,?), (z,?) } { (x,?), (y,1), (z,?) } { (x,?), (y,1), (z,2) } { (x,?), (y,?), (z,4) } { (x,?), (y,5), (z,4) } { (x,?), (y,1), (z,2) } { (x,?), (y,1), (z,2) }

38

slide-39
SLIDE 39

Dataflow Analysis

  • Reaching Definitions

 The assignment lab: var := exp reaches lab’ if there is

an execution where var was last assigned at lab

1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y − 1 } 6: y := 0

(adapted from Nielson, Nielson & Hankin) { (x,?), (y,?), (z,?) } { (x,?), (y,1), (z,?) } { (x,?), (y,1), (z,2), (y,5), (z,4) } { (x,?), (y,?), (z,4), (y,5) } { (x,?), (y,5), (z,4) } { (x,?), (y,1), (z,2), (y,5), (z,4) } { (x,?), (y,6), (z,2), (z,4) } { (x,?), (y,1), (z,2), (y,5), (z,4) }

39

slide-40
SLIDE 40

Dataflow Analysis

  • Build control-flow graph
  • Assign transfer functions
  • Compute fixed point

40

slide-41
SLIDE 41

Control-Flow Graph

1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y − 1 } 6: y := 0

1: y:=x 2: z:=1 3: y > 0 4: z=z*y 5: y=y-1 6: y:=0

41

slide-42
SLIDE 42

Transfer Functions

1: y:=x 2: z:=1 3: y > 0 4: z=z*y 5: y=y-1 6: y:=0

  • ut(1) = in(1) \ { (y,l) | l  Lab } U { (y,1) }
  • ut(2) = in(2) \ { (z,l) | l  Lab } U { (z,2) }

in(1) = { (x,?), (y,?), (z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) in(6) = out(3)

  • ut(4) = in(4) \ { (z,l) | l  Lab } U { (z,4) }
  • ut(5) = in(5) \ { (y,l) | l  Lab } U { (y,5) }
  • ut(6) = in(6) \ { (y,l) | l  Lab } U { (y,6) }
  • ut(3) = in(3)

42

slide-43
SLIDE 43

System of Equations

in(1) = { (x,?), (y,?), (z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) In(6) = out(3)

  • ut(1) = in(1) \ { (y,l) | l  Lab } U { (y,1) }
  • ut(2) = in(2) \ { (z,l) | l  Lab } U { (z,2) }
  • ut(3) = in(3)
  • ut(4) = in(4) \ { (z,l) | l  Lab } U { (z,4) }
  • ut(5) = in(5) \ { (y,l) | l  Lab } U { (y,5) }
  • ut(6) = in(6) \ { (y,l) | l  Lab } U { (y,6) }

F: ((Var x Lab) )12  ((Var x Lab) )12

43

slide-44
SLIDE 44

Least Fixed Point

  • We will see later why it exists
  • For now, mostly informally…

F: ((Var x Lab) )12  ((Var x Lab) )12 RD  RD’ when i: RD(i)  RD’(i) F is monotone: RD  RD’ implies that F(RD)  F(RD’) RD = (, ,…,) F(RD), F(F(RD) , F(F(F(RD)), … Fn(RD) Fn+1(RD) = Fn(RD)

RD F(RD)

 

F(F(RD))

… 

Fn(RD)

44

slide-45
SLIDE 45

Things that Should Trouble You

  • How did we get the transfer functions?
  • How do we know these transfer functions are

safe (conservative)?

  • How do we know that these transfer

functions are optimal?

45

slide-46
SLIDE 46

Abstract Interpretation

  • In the beginning, there was the trace

semantics…

1: y := x; 2: z := 1; 3: while y > 0 { 4: z := z * y; 5: y := y − 1 } 6: y := 0

(x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(y,6) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(z,4)(y,5)(y,6) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(z,4)(y,5)(z,4)(y,5)(y,6)

…

(x,?)(y,?)(z,?)(y,1)(z,2)(y,6)

46

slide-47
SLIDE 47

Collecting Semantics

1: y:=x 2: z:=1 3: y > 0 4: z=z*y 5: y=y-1 6: y:=0 (x,?)(y,?)(z,?)(y,1) (x,?)(y,?)(z,?) (y,1)(z,2) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5) (x,?)(y,?)(z,?)(y,1)(z,2) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(y,6) (x,?)(y,?)(z,?) (x,?)(y,?)(z,?)(y,1) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(z,4) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(z,4)(y,5) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5) (x,?)(y,?)(z,?) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(z,4)(y,5)(y,6) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5) (x,?)(y,?)(z,?)(y,1)(z,2) (y,6)

47

slide-48
SLIDE 48

System of Equations

in(1) = { (x,?)(y,?)(z,?) } in(2) = out(1) in(3) = out(2) U out(5) in(4) = out(3) in(5) = out(4) In(6) = out(3)

  • ut(1) = {   (y,1) |   in(1) }
  • ut(2) = {   (z,2) |   in(2) }
  • ut(3) = in(3)
  • ut(4) = {   (z,4) |   in(4) }
  • ut(5) = {   (y,5) |   in(5) }
  • ut(6) = {   (y,6) |   in(6) }

G: ((Trace) )12  ((Trace) )12

Trace = (Var x Lab)* TR G(TR)

 

G(G(TR))

… 

Gn(TR)

…

lfp(G)

48

slide-49
SLIDE 49

Galois Connection

  C (C) (A) A

 

(C)  A  C  (A)

49

slide-50
SLIDE 50

  C (C) (A) A

 

Reaching Definitions Revisited

  • DOM() = variables in 
  • SRD()(v) = l iff rightmost pair for v in  is (v,l)
  • (C) = { (v,SRD()(v)) | v  DOM()    C }
  • (A) = {  | v  DOM() : (v,SRD()(v) )  A }

(x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(y,6) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(z,4)(y,5)(y,6) (x,?)(y,?)(z,?)(y,1)(z,2)(y,6) (x,?),(z,4),(y,6) (x,?),(z,4),(y,6) (x,?),(z,2),(y,6)

(x,?),(z,2),(z,4),(y,6)

50

slide-51
SLIDE 51

  C (C) (A) A

 

Reaching Definitions Revisited

  • DOM() = variables in 
  • SRD()(v) = l iff rightmost pair for v in  is (v,l)
  • (C) = { (v,SRD()(v)) | v  DOM()    C }
  • (A) = {  | v  DOM() : (v,SRD()(v) )  A }

(x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(y,6) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)(z,4)(y,5)(y,6) (x,?),(z,4),(y,6) (x,?)(y,?)(z,?)(y,1)(z,2)(z,4)(y,5)…(z,4)(y,5)(y,6)

…

51

slide-52
SLIDE 52

Best (Induced) Transformer

  C A C’ A’ How do we figure out the abstract effect S# of a statement S ?

?

S# S

52

slide-53
SLIDE 53

Sound Abstract Transformer

  C A C’ A’ S# S Aopt

  S   (A)  S#(A)

53

slide-54
SLIDE 54

Soundness of Induced Analysis

RD F(RD)

 

F(F(RD))

… 

lfp(F) TR G(TR)

 

G(G(TR))

… 

Gn(TR)

…

lfp(G) (lfp(G)) 

(lfp(G))  lfp(  G  )  lfp(F)

54

slide-55
SLIDE 55

References

  • Patriot bug:

http://www.cs.usyd.edu.au/~alum/patriot_bug.html

Patrick Cousot’s NYU lecture notes

  • Zune bug:

http://www.crunchgear.com/2008/12/31/zune-bug-explained-in-detail/

  • Blaster worm:

http://www.sans.org/security- resources/malwarefaq/w32_blasterworm.php

  • Interesting CACM article

http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of- code-later/fulltext

  • http://journals.cambridge.org/download.php?file=%2FMSC%2F

MSC19_05%2FS0960129509990041a.pdf&code=d5af66869c188 1e31339879b90c07d0c

55