Download presentation
Presentation is loading. Please wait.
Published byJameson Daby Modified over 9 years ago
1
1APLAS05 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
2
2APLAS05 Outline Problem & Goal Type System Conclusion
3
3APLAS05 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. –…–…
4
4APLAS05 Example [ Program 1 ] main() { FILE* fp = fopen( “ f ”, ” w ” ); fprintf(fp, ” x ” ); fclose(fp); } [ Program 2 ] main() { FILE* fp = fopen( “ f ”, ” w ” ); if (fp) { fprintf(fp, ” x ” ); fclose(fp); } When a program analyzer assumes that fopen always opens the specified file, Miss the bug False alarm Path Sensitivity is Essential !
5
5APLAS05 A Path Sensitive Specification in FA Closed Opened Error fopen {ret>0} close read/ write/ close fopen {ret<=0} fopen read/ write
6
6APLAS05 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)
7
7APLAS05 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
8
8APLAS05 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.
9
9APLAS05 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.
10
10APLAS05 Outline Problem & Goal Type System Future work / Conclusion
11
11APLAS05 Our Type System Type ≈ lattice element instrumented with type variables Basically a subtype system (bounded polymorphism) We add flow and path sensitivity.
12
12APLAS05 Domain Design (Basic Types) ; ` P v MP { v P } ` v MP MZ T P MZMP ZP sign r1r1 T rnrn NR RC … resource id ALNA T allocation state CO T resource state A ` X 1 v X 2 if X 1 v X 2 2 Bas or X 1 v X 2 2 A £ value £ state of a resource
13
13APLAS05 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 Domain Design (Resource Heap) {(r 1,AL,O)} concretize( ) w {} w H ¢ [r 1 (AL,O)] H ¢ [r 1 (NA,C)] ¢ [r 1 (AL,O)] {h | h(r 1 ) = open} {(r 1,AL,O),(r 2,NA,C)} w w
14
14APLAS05 A Input Path (A) – a set of constraints over all type variables (input partition) { 1 v P, 1 v RC, v {( 1,AL,O)} } – order is defined as Output Paths ( ) – set of outputs : { (v 1, 1,H 1 ), …, (v n, n,H n ) } – order is defined as Domain Design (Set of Paths) A1 ` A2A1 ` A2 ` A1 v A2` A1 v A2 8 (v, ,H) 2 1. 9 (v ’, ’,h ’ ) 2 2. A ` v v v ’ Æ A ` v ’ Æ A ` H v H ’ ` 1v2` 1v2
15
15APLAS05 { v>, v>, v {} } vPvP v MZ x > 0 (x) = ( , ) , v P, v>, v {} , v MZ, v>, v {} , v P, v>, v {} 2, v MZ, v>, v {} 1, v>, v>, v {} 1 t 2, Input Path Partitioning / Merging
16
16APLAS05 (x) = ( , ) close x error “ not opened ” error “ not allocated ” error “ not resource ” { v>, v>, v {} } v>, v RC, v {( ,AL,O)} v>, v RC, v {( ,AL,C)} v>, v RC, v {( ,NA, > )} v>, v NR, v {} A, ,H ` close x : {(Z, ,H ¢ [R (AL,C)])} (x)=(R,D) A ` R v RC A ` H v {(R,AL,O)} { (Z, , ¢ [ (AL,C)]) } ,
17
17APLAS05 (x) = ( , ) open x error “ not closed ” error “ not allocated ” error “ not resource ” { v>, v>, v {} } v>, v RC, v {( ,AL,C)} v>, v RC, v {( ,AL,O)} v>, v RC, v {( ,NA, > )} v>, v NR, v {} A, ,H ` open x : {(P, ,H ¢ [R (AL,O)]), (Z, ,H) } (x)=(R,D) A ` R v RC A ` H v {(R,AL,C)} Z, ,H P, ,H ¢ [ (AL,O)] ,
18
18APLAS05 A set of input path(A)/output paths( ) pairs: – 8 , , . {(A 1, 1 ), …,(A n, n ) } – order is defined as Domain Design (Function Type) 8 (A 2, 2 ) 2 ts 2. 9 (A 1, 1 ) 2 ts 1. ` A 2 v A 1 Æ A 2 ` 1 v 2 8 (A 1, 1 ) 2 ts 1. 9 (A 2, 2 ) 2 ts 2. ` A 1 v A 2 Æ A 1 ` 1 v 2 A ` ts 1 v ts 2
19
19APLAS05 v MZ, v RC, v {( ,AL,C)} ] f(x) x=open x x > 0 use x close x f (x) v>, v>, v {} [x:( , )] v>, v>, v {} {} v P, v RC, v {( ,AL,O)} [x:( , )] v P, v>, v {} [x:( , )] Fixpoint !! v P, v RC, v {( ,AL,O)} [x:( , )] .[ (AL,C)] v MZ, v>, v {} [x:( , )] v MZ, v RC, v {( ,AL,C)} [x:( ,P)] .[ (AL,O)] [x:( ,Z)] v P, v RC, v {( ,AL,O)} .[ (AL,C)] v MZ, v RC, v {( ,AL,C)} {} .[ (AL,C)] v MZ, v RC, v {( ,C)} [x:( ,ZP) { .[ (AL,C)]} [ Typing Example ] v P, v RC, v {( ,AL,O)} .[ (AL,C)] v MZ, v RC, v {( ,AL,C)} open x : 8 , , . { v RC, v {( ,AL,C)} ! {(( ,P), ¢ [ (AL,O)]),(( ,Z), )} close x : 8 , , . { v RC, v {( ,AL,O)} ! {((NR,Z), ¢ [ (AL,C)])} use x : 8 , , . { v RC, v {( ,AL,O)} ! {((NR,Z), )} [x:( ,Z)] {} [x:( ,P)] {} [x:( ,ZP)] {} (={ .[( (AL,C)]} ] {})
20
20APLAS05 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) = { (A 1, 1 ), , (A n, n ) }, then A i, ,H ` e : i. Soundness
21
21APLAS05 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.
22
22APLAS05 Ongoings and future work Type based dynamic allocation Multiple error message Resource type based slicing Modular pointer analysis specialized for this problem Specification language
23
23APLAS05 Conclusion We formalized a sound path-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.
24
24APLAS05 Thank You
25
25APLAS05 Demo
26
26APLAS05
27
27APLAS05 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)
28
28APLAS05 Ongoings and future work Type based dynamic allocation v {(r i,NA,X)} ! ¢ [ ][r i (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 (2 15 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 r i is program point of alloc i now is program point of allocator function (instantiated)
29
29APLAS05 v P, v>, v {} [fp:( 2, 2 )], { v>, v>, v {} } vPvP v MZ x > 0 (x) = ( , ) , v P, v>, v {} , v MZ, v>, v {} , v MZ, v>, v {} [fp:( 1, 1 )], Alias Can not be combined ! 1 # 2 by no interprocedural alias assumption
30
30APLAS05 The Resource Language
31
31APLAS05 Dynamic Semantics
32
32APLAS05 Types
33
33APLAS05 Typing Rule (Resource API) output path generator
34
34APLAS05 Resource Path Sensitive Join
35
35APLAS05 Typing Rule (Branch) input path generator
36
36APLAS05 Typing Rule (Func Abstr / App) input/output path generator
37
37APLAS05 Typing Rule (others)
38
38APLAS05 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 A c )
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.