KleeNet

Sasnauskas, Raimondas; Landsiedel, Olaf; Alizai, Muhammad Hamad; Weise, Carsten; Kowalewski, Stefan; Wehrle, Klaus

doi:10.1145/1791212.1791235

Cited by 98 publications

(11 citation statements)

References 43 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In addition, despite exploring all code paths, symbolic execution does not explore all system execution paths, such as different event interleavings. Techniques exist that can add artificial branching points to a program to inject faults or explore different event orderings [21,25], but at the expense of extra complexity. As such, symbolic execution is insufficient for testing OpenFlow applications.…”

Section: Background On Symbolic Executionmentioning

confidence: 99%

“…While model checking [18,17,15,16,19] and symbolic execution [28,20,21] are automatic techniques, a drawback is that they typically require a closed system, i.e., a system (model) together with its environment. Typically, the creation of such an environment is a manual process (e.g., [25]). NICE re-uses the idea of model checking-systematic state-space exploration-and combines it with the idea of symbolic executionexhaustive path coverage-to avoid pushing the burden of modeling the environment on the user.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Systematically testing OpenFlow controller applications

et al. 2015

View full text Add to dashboard Cite

The emergence of OpenFlow-capable switches enables exciting new network functionality, at the risk of programming errors that make communication less reliable. The centralized programming model, where a single controller program manages the network, seems to reduce the likelihood of bugs. However, the system is inherently distributed and asynchronous, with events happening at different switches and end hosts, and inevitable delays affecting communication with the controller. In this paper, we present efficient, systematic techniques for testing unmodified controller programs. Our NICE tool applies model checking to explore the state space of the entire system-the controller, the switches, and the hosts. Scalability is the main challenge, given the diversity of data packets, the large system state, and the many possible event orderings. To address this, we propose a novel way to augment model checking with symbolic execution of event handlers (to identify representative packets that exercise code paths on the controller). We also present a simplified OpenFlow switch model (to reduce the state space), and effective strategies for generating event interleavings likely to uncover bugs. Our prototype tests Python applications on the popular NOX platform. In testing three real applications-a MAC-learning switch, in-network server load balancing, and energy-efficient traffic engineering-we uncover thirteen bugs.

show abstract

Section: Background On Symbolic Executionmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Systematically testing OpenFlow controller applications

et al. 2015

View full text Add to dashboard Cite

show abstract

“…Simulators, such as TOSSIM , and emulators, such as Avrora [Titzer et al 2005] or COOJA [Österlind et al 2006], enable the testing of complete sensornet systems and protocol suites at scale. Similarly, testbeds like Motelab [WernerAllen et al 2005], Kansei [Ertin et al 2006], or our own ones [Iwanicki et al 2008;Michalowski et al 2012] are invaluable for assessing the performance of complete systems or self-contained subsystems and protocols on actual sensornet hardware.…”

Section: Related Workmentioning

confidence: 99%

“…Conversely, formal methods, like symbolic execution [Sasnauskas et al 2010] and model checking [Li and Regehr 2010], do enable exhaustively analyzing the control flow paths of a system. In effect, they are indispensable for identifying software flaws due to unpredicted interactions between various modules of the system.…”

Section: Related Workmentioning

confidence: 99%

“…However, because the system is analyzed as a whole, the state space that formal methods have to explore grows exponentially with software and network size. In effect, to make the verification process feasible, parts of the analyzed code-typically hardware driver code or complex protocol code-have to be abstracted out [Li and Regehr 2010;Sasnauskas et al 2010]. Not only is this laborious, but it may also impair the overall software reliability.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Bringing Modern Unit Testing Techniques to Sensornets

Iwanicki

Horban

Glazar

et al. 2014

ACM Trans. Sen. Netw.

View full text Add to dashboard Cite

Unit testing, an important facet of software quality assurance, is underappreciated by wireless sensor network (sensornet) developers. This is likely because our tools lag behind the rest of the computing field. As a remedy, we present a new framework that enables modern unit testing techniques in sensornets. Although the framework takes a holistic approach to unit testing, its novelty lies mainly in two aspects. First, to boost test development, it introduces embedded mock modules that automatically abstract out dependencies of tested code. Second, to automate test assessment, it provides embedded code coverage tools that identify untested control flow paths in the code. We demonstrate that in sensornets these features pose unique problems, solving which requires dedicated support from the compiler and operating system. However, the solutions have the potential to offer substantial benefits. In particular, they reduce the unit test development effort by a few factors compared to existing solutions. At the same time, they facilitate obtaining full code coverage, compared to merely 57-72% that can be achieved with integration tests. They also allow for intercepting and reporting many classes of runtime failures, thereby simplifying the diagnosis of software flaws. Finally, they enable fine-grained management of the quality of sensornet software.

show abstract

Memory models in symbolic execution: key ideas and new thoughts

Borzacchiello

Coppa

D’Elia

et al. 2019

Software Testing Verif & Rel

View full text Add to dashboard Cite

Symbolic execution is a popular program analysis technique that allows seeking for bugs by reasoning over multiple alternative execution states at once. As the number of states to explore may grow exponentially, a symbolic executor may quickly run out of space. For instance, a memory access to a symbolic address may potentially reference the entire address space, leading to a combinatorial explosion of the possible resulting execution states. To cope with this issue, state-of-the-art executors either concretize symbolic addresses that span memory intervals larger than some threshold or rely on advanced capabilities of modern satisfiability modulo theories solvers. Unfortunately, concretization may result in missing interesting execution states, for example, where a bug arises, while offloading the entire problem to constraint solvers can lead to very large query times. In this article, we first contribute to systematizing knowledge about memory models for symbolic execution, discussing how four mainstream symbolic executors deal with symbolic addresses. We then introduce MEMSIGHT, a new approach to symbolic memory that reduces the need for concretization: rather than mapping address instances to data as previous approaches do, our technique maps symbolic address expressions to data, maintaining the possible alternative states resulting from the memory referenced by a symbolic address in a compact, implicit form. Experiments on prominent programs show that MEMSIGHT, which we implemented in both ANGR and KLEE, enables the exploration of states that are unreachable for memory models that perform concretization and provides a performance level comparable with memory models relying on advanced solver theories. MEMORY MODELS IN SYMBOLIC EXECUTION: KEY IDEAS AND NEW THOUGHTS3 of 35 used in the context of state-of-the-art symbolic executors. A crucial design goal for our approach is that it should be general enough not only to support bug detection but also to be valuable in application contexts where users are interested in possible consequences of these bugs, for example, understanding how they can be exploited.Our approach, which we call MEMSIGHT, natively accounts for merging [3,4], a mainstream performance enabler in symbolic executors. We integrated MEMSIGHT into the state-of-the-art symbolic executors ANGR [5] and KLEE [6]: an experimental evaluation shows that MEMSIGHT allows for broader state exploration on prominent benchmarks analysed with ANGR, while it provides valuable run-time speedups when symbolically executing real-world programs under KLEE.A preliminary version [7] of this work appeared in the Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE 2017), where we introduced the main idea behind MEMSIGHT (Section 3) and presented a preliminary experimental evaluation related to MEMSIGHT when integrated into ANGR (Section 5.2.2). ‡ For our example to be meaningful, we assume that b resides in memory rather than in a CPU register. § In SMT-LIB [9], the theories of...

show abstract

KleeNet

Cited by 98 publications

References 43 publications

Systematically testing OpenFlow controller applications

Systematically testing OpenFlow controller applications

Bringing Modern Unit Testing Techniques to Sensornets

Memory models in symbolic execution: key ideas and new thoughts

Contact Info

Product

Resources

About