Checking Memory Safety and Test Generation Using Blast

1
Checking Memory Safety and Test Generation Using
Blast

• By Pashootan Vaezipoor

Computing Science Dept of Simon Fraser University
2
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

3
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

4
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 optimized runtime checks
• Use Blast to remove some of the remaining checks
• Ccured optimisation removes 50 of checks
• The output program runs 2 times slower than the
  original one

5
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

6
Experiments
7
Test Generation

• Consider the following example that tries to find
  the middle of three values, along with its CFA

8
Example

• The task of finding a test vector for a program
  location consists of these steps
• Model Checking First we check for locations
  reachability
• Blast makes the path in the ART
• In the Example mzassume(yltz)assume(xlty)
• Tests from counterexamples
• Build the path formula
• mz yltz xlty
• Find the satisfying assignment for the formula
• X0, y1, z2, m2

9
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)

10
BLAST Test Framework

• A test framework comprises the followings
• Suitable program representation
• CFA
• Test vector representation
• A vector of values for initial variables and
  functions return values and program input
• An adequacy criterion
• A test generation procedure
• Test driver

11
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

12
Test suit Generation

• The model checking algorithm takes as input a set
  of CFAs and a con?guration (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 satis?able

13
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)

14
Example

• The DFS order for the middle is like this
• ltL1, L2, L7, L8, L3, L6, L10, L13, L15, L12, L9,
  L5gt

15
Experiment Results