Extending typestate checking using conditional liveness analysis

Abstract

We present a practical extension to typestate checking which is capable of proving programs free of uninitialized variable errors even when these programs contain conditionally initialized variables where the initialization of a variable depends upon the equality of one or more '@tagn variables to a constant. The user need not predeclare the relationship between a conditionally initialized variable and its tags, and this relationship may change from one point in the progrqm to another. Our technique generalizes liveness analysis to conditional liveness analysis. Like typestate checking, our technique incorporates a dataflow analysis algorithm in which each point in a program is labeled with a lattice point describing statically tracked information, including the initialization of variables. The labeling is then used to check for programming errors such as referencing a variable which may be uninitialized. Our technique incorporates a more expressive lattice, including predicates of the form: "I is initialized if y equals 2." Because the number of tags per variable is small, the added complexity of the analysis is usually small. The efficiency of our technique is due, to a large extent, to the fact that we use a backwards analysis of the program (instead of the forward analysis used in the original typestate checking algorithm). Our results suggest that backwards analysis-tracking only those properties which need to hold to make the subsequent statements correct-can be more efficient than forward analysis-tracking all properties which are made true by the preceding statements. We conclude with some additional applications of our techniques to program checking. Index r e m-Conditionals, dataflow analysis, liveness analysis, program correctness, typestate checking. 'These annotations indicate the change of typestate that a parameter will occur in the function body (e.g., will become initialized or become uninitialized). Without these annotations, one could not typestate check a module without seeing the code body of the function being called. With these annotations, one can prove a module to be typestate correct independent of the function bodies being invoked.

Typestate Verification: Abstraction Techniques and Complexity Results

“…Some approaches avoid the issue: e.g., the original work on typestate verification [24,23] did not allow any aliasing, and more recent work on typestate verification based on linear types [7] also restrict aliasing severely. Some other approaches (e.g.…”

“…A technique that has received particular attention is that of finite state or typestate verification (e.g., see [24,23,19,5,7,3,8,12,11,16,1]). In this model, objects of a given type may exist in one of several states; the operations permitted on an object depend on the state of the object, and the operations may potentially alter the state of the object.…”

Component Composition for Embedded Systems Using Semantic Aspect-Oriented Programming

“…But in many cases, properties that do change are as important as properties that do not. Recognizing the benefit of capturing these changes, researchers have developed systems in which the type of the object changes as the values stored in its fields change or as the program invokes operations on the object [188,187,74,206,207,54,109,84]. These systems integrate the concept of changing object states into the type system.…”

Towards security testing with taint analysis and genetic algorithms

“…Originally called type-state analysis [18], taint analysis has been largely adopted to detect inadequate or missing input validation, resulting in cross site scripting [22] [10], SQL-injection [9] and buffer overflow [16] vulnerabilities. In order to mitigate inaccuracy of pure taint analysis due to conservativity, more sophisticated analyses have been integrated, such as string analysis [22], program slicing [11], points-to analysis [12] and model checking [20].…”