<p>Forward SE is easier to implement, composes better with other testing methods, and thus is more scalable.</p>

<p>Usually, on industrial-scale workloads, it's not possible to enumerate all paths in the program under test -- there are simply too many paths. So we need some way to deal with this and sample only a subset of paths, while still having a reasonable chance of finding bugs.  With forward SE, there is an easy way to deal with this: if you have a test case, you can run the program concretely for a while, then switch to forward SE partway through execution.  Or, you can run the program concretely until it terminates, recording the path it took, and use SE to generate new inputs that will cause it to go down a similar but not identical path.  The state-of-the-art tools tend to combine fuzzing (random testing) with SE, and this approach is a nice way to enable that sort of composition.</p>

<p>Second, forward SE has implementation benefits.  Inevitably there are some kinds of operations that you can't or don't want to model symbolically (e.g., floating point, system calls, etc.).  With forward SE, that's no problem: you just execute the program concretely and keep only part of the state symbolic, treating the results of those operations as concrete (you concretize by forcing their inputs to match the observed concrete value, and same for the outputs).  It's usually not possible to do that concretization with backwards SE.  So forward SE allows "concolic execution", where some of the state of the program is concrete (a single value) and some is treated as symbolic (represented by some variables that we accumulate constraints on).</p>

<p>Finally, many modern tools are path-based: they consider a single path through the program, and construct a path expression -- a set of constraints that characterize the set of inputs that will cause the program to follow that path.  This is convenient for multiple reasons.  When you take this approach, the differences between forward SE and backwards SE largely disappear, as there is no state merging; you only consider a single path at a time.  So if you're taking this approach, in some sense you don't need to choose between the two, or the choice is inconsequential (both are basically equivalent) -- you can choose whichever you want based on which one you find a more convenient  way to think about it.</p>

CC BY-SA 3.0
2017-04-02T17:13:26.910Z
2017-04-02T17:13:26.910Z
D.W.
<p>Looking at the <a href="http://archive.darpa.mil/cybergrandchallenge/" rel="noreferrer">DARPA’s Cyber Grand Challenge</a>, it seems that (forward) Symbolic Execution (SE) is the tool of choice for all the top teams. For example:</p>

<ul>
<li><a href="https://forallsecure.com/blog/2016/02/09/unleashing-mayhem/" rel="noreferrer">Mayhem</a>, the winner of the $2 millions prize</li>
<li><a href="http://cs.ucsb.edu/~chris/research/doc/ndss16_driller.pdf" rel="noreferrer">Driller</a>, ranked 2nd or 3rd.</li>
</ul>

<p>Maybe this is a stupid question, but if the purpose is to find the input that reach a location, e.g. the one that causes <code>SIGSEGV</code>, then intuitively going backward from that location is much easier that searching from forward. However, obviously those well-known scientists did not think so, and I wonder why.</p>

<p>Moreover, papers about forward SE appear in all software engineering conferences, and there is a survey every 2 or 3 years. But I don't remember the last time I read a paper about backward SE (that's why there is this possibly stupid question).</p>

<p>Are there any challenges that make backward SE either:</p>

<ul>
<li>significantly more difficult to implement than forward SE, or</li>
<li>much less scalable than forward SE, or</li>
<li>...</li>
</ul>

<program-analysis>
Why backward symbolic execution is so unpopular?
sean
# Why backward symbolic execution is so unpopular?

(Asked by: username_0 on 2017-04-02)

Looking at the [DARPA’s Cyber Grand Challenge](http://archive.darpa.mil/cybergrandchallenge/), it seems that (forward) Symbolic Execution (SE) is the tool of choice for all the top teams. For example:

* [Mayhem](https://forallsecure.com/blog/2016/02/09/unleashing-mayhem/), the winner of the $2 millions prize
* [Driller](http://cs.ucsb.edu/~chris/research/doc/ndss16_driller.pdf), ranked 2nd or 3rd.

Maybe this is a stupid question, but if the purpose is to find the input that reach a location, e.g. the one that causes `SIGSEGV`, then intuitively going backward from that location is much easier that searching from forward. However, obviously those well-known scientists did not think so, and I wonder why.

Moreover, papers about forward SE appear in all software engineering conferences, and there is a survey every 2 or 3 years. But I don't remember the last time I read a paper about backward SE (that's why there is this possibly stupid question).

Are there any challenges that make backward SE either:

* significantly more difficult to implement than forward SE, or
* much less scalable than forward SE, or
* ...

**Tags:** program-analysis


---

## 1 answers

### Answer by username_1 on 2017-04-02. Score: 6 | Accepted answer

Forward SE is easier to implement, composes better with other testing methods, and thus is more scalable.

Usually, on industrial-scale workloads, it's not possible to enumerate all paths in the program under test -- there are simply too many paths. So we need some way to deal with this and sample only a subset of paths, while still having a reasonable chance of finding bugs. With forward SE, there is an easy way to deal with this: if you have a test case, you can run the program concretely for a while, then switch to forward SE partway through execution. Or, you can run the program concretely until it terminates, recording the path it took, and use SE to generate new inputs that will cause it to go down a similar but not identical path. The state-of-the-art tools tend to combine fuzzing (random testing) with SE, and this approach is a nice way to enable that sort of composition.

Second, forward SE has implementation benefits. Inevitably there are some kinds of operations that you can't or don't want to model symbolically (e.g., floating point, system calls, etc.). With forward SE, that's no problem: you just execute the program concretely and keep only part of the state symbolic, treating the results of those operations as concrete (you concretize by forcing their inputs to match the observed concrete value, and same for the outputs). It's usually not possible to do that concretization with backwards SE. So forward SE allows "concolic execution", where some of the state of the program is concrete (a single value) and some is treated as symbolic (represented by some variables that we accumulate constraints on).

Finally, many modern tools are path-based: they consider a single path through the program, and construct a path expression -- a set of constraints that characterize the set of inputs that will cause the program to follow that path. This is convenient for multiple reasons. When you take this approach, the differences between forward SE and backwards SE largely disappear, as there is no state merging; you only consider a single path at a time. So if you're taking this approach, in some sense you don't need to choose between the two, or the choice is inconsequential (both are basically equivalent) -- you can choose whichever you want based on which one you find a more convenient way to think about it.


---

