150 likes | 275 Views
Checking Memory Safety and Test Generation Using B last. By: Pashootan Vaezipoor. Computing Science Dept of Simon Fraser University. Memory Safety. A program is memory safe if: Only accesses objects it has allocated Or the ones that it has been granted access
E N D
Checking Memory Safety and Test Generation Using Blast By: Pashootan Vaezipoor Computing Science Dept of Simon Fraser University
Memory Safety • A program is memory safe if: • Only accesses objects it has allocated • Or the ones that it has been granted access • Null pointer dereferencing is an aspect of memory safety • Meaning that we shall not access a null variable in our program
Example • In this code, the programmer has instrumented the program to check ptr to see if it is null • We want to do this instrumentation automatically! • This way, we are reducing the memory safety problem to a reachability problem
Possible Strategies • Strategy #1: • Annotate all memory accesses • Run Blast on the result • Check if it violates • We can do it much easier using a type-based approach • Each annotation should be checked independently • Strategy #2: • Use Ccured to insert the optimizedruntime checks • Use Blast to remove some of the remaining checks • Ccuredoptimisation removes 50% of checks • The output program runs 2 times slower than the original one
Technical Issues • CCured adds a call to the __CHECK_NULL(p) for each unsafe pointer access • Blast replaces __CHECK_NULL(p) with __BLAST_CHECK_NULL(p) • Blast checks if the __BLAST_ERROR is reachable • Outcomes: • Not reachable: remove the call • Reachable: Error path is created • Check must remain • The error might be a simple program bug (malloc) • Blast fails: Check must remain
Test Generation • Consider the following example that tries to find the middle of three values, along with it’s CFA:
Example • The task of finding a test vector for a program location consists of these steps: • Model Checking: First we check for location’s reachability • Blast makes the path in the ART • In the Example: m=z;assume(y<z);assume(x<y) • Tests from counterexamples: • Build the path formula • m=z ^ y<z ^ x<y • Find the satisfying assignment for the formula • X=0, y=1, z=2, m=2
Example • Since the path to L5 is feasible, the PF is satisfiable • We have to repeat this task for all locations in the program to find the location coverage of the program • We have some of the vectors here, but L13 and L15 are not covered (hence unreachable)
BLAST Test Framework • A test framework comprises the followings: • Suitable program representation • CFA • Test vector representation • A vector of values for initial variables and function’s return values and program input • An adequacy criterion • A test generation procedure • Test driver
BLAST Test Framework (Coverage Goals) • Test adequacy criterion is a set of coverage goals that determine when the program has been tested thoroughly • We do that using target predicate coverage
Test suit Generation • The model checking algorithm takes as input a set of CFAs and a configuration (q, p) of target location and target predicate • Algorithm returns either with outcome • O1: a complete ART T that is safe w.r.t. (q, p) • O2: a path from the root node to a node n : (q, ·,ϕ) such that ϕ ∧ p is satisfiable
Steps of the Test Generator • Step 1: • The CFA locations are numbered in DFS order and put in a worklist • Step 2: • If the worklist is empty, we are done • Else we invoke the Model checker with current ART and the config (q, p) • Step 3: • Outcome O1 : • No Test Vectors exist • Outcome O2: • We have found a p-reachable location q (use it for test generation)
Example • The DFS order for the middle is like this: • <L1, L2, L7, L8, L3, L6, L10, L13, L15, L12, L9, L5>