A Path Sensitive Type System for Resource Usage Verification of C like languages

1. A Path Sensitive Type System for Resource Usage Verification of C like languages Korea Advanced Institute of Science and Technology Hyun-Goo Kang, Youil Kim, Taisook Han, Hwansoo Han APLAS05

2. Outline • Problem & Goal • Type System • Conclusion APLAS05

3. Resource Usage Protocol • A program should use resources in a valid way. • Such a protocol is usually specified by a correct sequence of actions on the resource, which is recognizable by a finite state machine. • Example • A file should be open before being written. • A memory cell should not be accessed after deallocation. • An acquired lock should be released eventually. • … APLAS05

4. Example When a program analyzer assumes that fopen always opens the specified file, [ Program 1 ] main() { FILE* fp = fopen(“f”,”w”); fprintf(fp,”x”); fclose(fp); } Miss the bug [ Program 2 ] main() { FILE* fp = fopen(“f”,”w”); if (fp) { fprintf(fp,”x”); fclose(fp); } } False alarm Path Sensitivity is Essential ! APLAS05

5. read/ write fopen {ret>0} fopen {ret<=0} close Error Closed Opened fopen read/ write/ close A Path Sensitive Specification in FA APLAS05

6. Related Works • Path insensitive verification : actions in finite automata specification are limited as syntactically identifiable sets • Resource Usage Analysis (Igarashi & Kobayashi) • Vault (DeLine & Fahndrich) • Path sensitive but whole program analysis • SLAM (Ball & Rajamani @ MSR), BLAST (Henzinger et. al. @ UCB) • ESP (Das et. al. @ MSR) • Path sensitive and modular, but unsound • Saturn(Yichen Xie, Alex Aiken @ Stanford) APLAS05

7. Our Goal is • To design a path sensitive resource usage analysis • To design it as a modular analysis for modular specification/verification and scalability • To design it as an automatic and sound analysis APLAS05

8. Observations • Path sensitivity is essential. • Values to identify paths are mainly constants and limited to some simple integer values. • A pointer to file-like resources is normally used just as a reference. • Intraprocedural alias of resources is often but interprocedural alias of resources is not frequent. • Resource allocation rarely appears within loops. Even if it appears, every resource allocated in the loop should be deallocated or should have the same specification. APLAS05

9. Selected Abstraction • Domain abstraction • Resource states are traced in concrete level. (no abstraction, finite) • Values that identify paths are traced with a constant propagation lattice. • Join at merge point • If resource contexts from different paths are different, then we collect (union) them as a set. • Otherwise we do normal join over our lattice type. (t) • Resource identification • Resources are identified by allocation points. All resources allocated in the same program point should satisfy the same resource usage specification. • Tracing resources • Alias information is traced in the path sensitive way within function body under the assumption of no interprocedural alias. APLAS05

10. Outline • Problem & Goal • Type System • Future work / Conclusion APLAS05

11. Our Type System • Type ≈ lattice element instrumented with type variables • Basically a subtype system (bounded polymorphism) • We add flow and path sensitivity. APLAS05

12. T T T T C O ZP MZ MP AL NA RC  NR  M Z P … r1 rn   sign resource id Domain Design (Basic Types)   allocation state resource state £ £ value state of a resource A ` X1v X2 if X1vX22 Bas or X1v X2 2 A ;` P v MP {  v P } `  v MP APLAS05

13. {} w w {(r1,AL,O),(r2,NA,C)} Domain Design (Resource Heap) • Natural definition of resource heap would be • resource Id ! (allocation state, resource state) • But we are interested only in the resources related to the function inferred. • constrained heap • heap update history {h | h(r1) = open} {(r1,AL,O)} concretize()  w H¢[r1 (AL,O)] w H¢[r1 (NA,C)]¢[r1 (AL,O)] APLAS05

14. A1`A2 `A1vA2 8 (v,,H)21. 9(v’,’,h’)22. A` vvv’Æ A`v’Æ A` HvH’ `1v2 Domain Design (Set of Paths) • A Input Path (A) • a set of constraints over all type variables (input partition) { 1vP, 1vRC, v{(1,AL,O)} } • order is defined as • Output Paths () • set of outputs : { (v1,1,H1), …, (vn,n,Hn) } • order is defined as APLAS05

15. vMZ, v>, v{} vMZ,v>, v{} 1,  ,  vP, v>, v{} vP,v>, v{} 2,  ,  x > 0 v>, v>, v{} 1t2,  Input Path Partitioning / Merging vMZ { v>, v>, v{} } ,  vP (x) = (,) APLAS05

16. error “not resource” error “not allocated” error “not opened” close x v>, vNR, v{} v>, vRC, v{(,NA,>)} { v>, v>, v{} } ,  v>, vRC, v{(,AL,C)} v>, vRC, v{(,AL,O)} (x) = (,) (x)=(R,D) A ` R v RC A ` H v {(R,AL,O)} A,,H ` close x : {(Z,,H¢[R  (AL,C)])} { (Z, , ¢[ (AL,C)]) } APLAS05

17. open x error “not resource” error “not allocated” error “not closed” v>, vNR, v{} v>, vRC, v{(,NA,>)} { v>, v>, v{} } ,  v>, vRC, v{(,AL,O)} v>, vRC,  v{(,AL,C)} (x) = (,) (x)=(R,D) A ` RvRC A ` H v {(R,AL,C)} A,,H ` open x : {(P,,H¢[R (AL,O)]), (Z,,H) } P,,H¢[ (AL,O)] Z,,H APLAS05

18. 8(A2,2)2ts2. 9(A1,1)2ts1. ` A2vA1Æ A2`1v2 8(A1,1)2ts1. 9(A2,2)2ts2. ` A1vA2Æ A1`1v2 A ` ts1vts2 Domain Design (Function Type) • A set of input path(A)/output paths() pairs: • 8,,. {(A1,1),…,(An,n) } • order is defined as APLAS05

19. f (x) x > 0 use x x=open x f(x) close x open x : 8,,. {vRC, v{(,AL,C)} ! {((,P),¢[(AL,O)]),((,Z),)} close x : 8,,. {vRC, v{(,AL,O)} ! {((NR,Z),¢[(AL,C)])} use x : 8,,. {vRC, v{(,AL,O)} ! {((NR,Z),)} Typing Example v>,v>, v{} [x:(,)]  {} v>, v>, v{} vP,v>, v{} [x:(,)]  vMZ,v>, v{} [x:(,)]  vP,vRC,v{(,AL,O)} .[(AL,C)] {} vMZ,vRC,v{(,AL,C)} vP,vRC,v{(,AL,O)} .[(AL,C)] vP,vRC,  v{(,AL,O)} [x:(,)]  vMZ,vRC, v{(,AL,C)} [x:(,P)] .[(AL,O)] [x:(,Z)]  .[(AL,C)] vMZ,vRC,v{(,AL,C)} Fixpoint !! vP,vRC,  v{(,AL,O)} [x:(,)] .[(AL,C)] vMZ,vRC,v{(,AL,C)} vMZ,vRC,v{(,C)} [x:(,ZP) {.[(AL,C)]} [x:(,ZP)] {} [x:(,P)] {} [x:(,Z)] {} ] ] (={.[((AL,C)]}]{}) [ APLAS05

20. Soundness • Theorem 1 [Correctness of Type System] If a configuration C is typed, then C is (finished) or it goes without type error. • Two main lemma : subject reduction & progress • Theorem 2 [Correctness of Algorithm] If I(A,,H,e) = { (A1,1), , (An,n) }, then Ai,,H ` e : i. APLAS05

21. Implementation • We have implemented a prototype, and experimented it with some C programs. • The prototype extends the algorithm in the paper: • Partitions input constraints more lazily. • Handles global variables and heap storage. • Detects resource leaks. APLAS05

22. Ongoings and future work • Type based dynamic allocation • Multiple error message • Resource type based slicing • Modular pointer analysis specialized for this problem • Specification language APLAS05

23. Conclusion • We formalized a soundpath-sensitive analysis for resource usage protocols. • Our analysis is modular; the analysis summarizes each function as a type scheme, without using any user annotations. • In the paper, we also showed how to handle dynamic resource allocation and aliases. APLAS05

24. Thank You APLAS05

25. Demo APLAS05

26. APLAS05

27. Related Works • Path insensitive verification : actions in finite automata specification are limited as syntactically identifiable sets • Resource Usage Analysis (Igarashi & Kobayashi) • Vault (DeLine & Fahndrich) • Path sensitive but whole program analysis • SLAM (Ball & Rajamani @ MSR), BLAST (Henzinger et. al. @ UCB) • C2BP. Then, model check • ESP (Das et. al. @ MSR) • Ideas of selective join • Lighter-weighted than SLAM/BLAST. But still whole program analysis • Path sensitive and modular, but unsound • Saturn(Yichen Xie, Alex Aiken @ Stanford) • Program constructs  Bit level boolean constraint (equation) • Inference  SAT solving • Unsound : assumption of no alias between arguments, finite loop unrolling • Blind summary : not symbolic (their optimization : slicing query dependent part after whole equation generation) APLAS05

28. Ongoings and future work • Type based dynamic allocation v {(ri,NA,X)} !¢[][ri (AL,Y)] v {(,NA,X)} ―alloc({})!¢[][ (AL,Y)] • Multiple error message • Better error recovery algorithm to remove multiple false alarm caused by one bug • Resource type based slicing • In GCC package of SPEC95 benchmark, there is a function that opens 15 file concurrently (215 path), but if we slice it based on FILE* type, then we can accelerate the complexity of inference to 2£15 safely • Pointer / structure / array • Modular pointer analysis specialized for this problem • Specification Language ri is program point of alloci now  is program point of allocator function (instantiated) APLAS05

29. vMZ,v>, v{} ,  vP,v>, v{} ,  x > 0 vP, v>, v{} [fp:(2,2)],  vMZ, v>, v{} [fp:(1,1)],  Alias vMZ { v>, v>, v{} } ,  vP (x) = (,) Can not be combined ! 1 # 2 by no interprocedural alias assumption APLAS05

30. The Resource Language APLAS05

31. Dynamic Semantics APLAS05

32. Types APLAS05

33. Typing Rule (Resource API) output path generator APLAS05

34. Resource Path Sensitive Join APLAS05

35. Typing Rule (Branch) input path generator APLAS05

36. Typing Rule (Func Abstr / App) input/output path generator APLAS05

37. Typing Rule (others) APLAS05

38. Retrospection (what’s hard) • To be modular • Managing/Inferring , ,  part in sound/symbolic way is complex • To be a lazy input path (constraint) partitioning algorithm • Assumption set is not boolean complete lattice. (We don’t have exact Ac) APLAS05