Symbolic execution-model equivalence & applications

Symbolic execution runs programs with symbolic inputs instead of concrete ones. A symbolic input models a range of values, which may be constrained or modified during program execution. The output of symbolic execution is the set of all possible program execution paths, and for each path and variable v — the symbolic expression to which v is bound, i.e. the set of constraints on v on the path at hand. Consider an example where the integer a is declared symbolic, meaning it can take any integer value, and a program that executes if (a>0): the execution engine will explore two paths after the instruction, one where the constraint a>0 holds, and one where its negation a<=0 holds. Symbolic execution has been recently used to verify network dataplanes [1, 3, 2]. When applied to the dataplane code (e.g. middlebox C code), it can capture a series of interesting bugs including low level memory access errors [1], but it does not scale very well, with verification times in the order of minutes to hours per box. Thus, all symbolic execution papers including [1, 3, 2] use models of the code instead of real code to perform symbolic execution in reasonable time; these models work at various abstraction levels and are coded in domain-specific languages (e.g. SEFL [3]) or in C code. By optimizing models for fast symbolic execution, it is possible to test fairly large networks in tens of seconds [3, 2]. There is one downside: existing works offer no strong guarantees that the model is a faithful representation of the real code. We present a possible solution to this problem.