Efficient memory safety for TinyOS

Abstract

Reliable sensor network software is difficult to create: applications are concurrent and distributed, hardware-based memory protection is unavailable, and severe resource constraints necessitate the use of unsafe, low-level languages. Our work improves this situation by providing efficient memory and type safety for TinyOS 2 applications running on the Mica2, MicaZ, and TelosB platforms. Safe execution ensures that array and pointer errors are caught before they can corrupt RAM. Our contributions include showing that aggressive optimizations can make safe execution practical in terms of resource usage; developing a technique for efficiently enforcing safety under interrupt-driven concurrency; extending the nesC language and compiler to support safety annotations; finding previously unknown bugs in TinyOS; and, finally, showing that safety can be exploited to increase the availability of sensor networks applications even when memory errors are left unfixed.

On software verification for sensor nodes

“…Advantageously, this generation is completely automatic, with CBMC analysing an array's declaration to !nd the index bounds; SafeTinyOS (Cooprider et al, 2007), for example, has programmers explicitly type-annotate arrays with access bounds instead.…”

“…To this end, in the process of program transformation, tos2cprover reports to the programmer the list of encountered memory dereferences, and translates the constant address implicated to its section in the memory map, e.g., for the line: In some cases (particularly for dereferences of address 0x0), an inspection of this report is advisable to sort any null pointers from legitimate peripheral access. A similar approach is taken by SafeTinyOS (Cooprider et al, 2007), which has programmers explicitly mark legal dereferences of constants with a trusted type, and thus make null-pointer dereferences visible.…”

“…While a necessary solution to ensure safe execution in all execution contexts, runtime error detection for deployments is potentially followed by the expensive redeployment of software, and could instead be preceded by compile-time means of error detection to save on redeployment efforts. Safe TinyOS (Cooprider et al, 2007) detects memory and type violations in deployed TinyOS code, and transfers control to a fault handler, which either reboots or powers down after sending a concise failure report to its base station. The failure report identi!es the error type and its source code location (but does not give an execution trace clarifying the context which caused the error); the failure report is used to debug the code post-deployment.…”

Bug-Free Sensors: The Automatic Verification of Context-Aware TinyOS Applications

“…TinyOS's own nesC compiler has a built-in simplistic data-race detector. Safe TinyOS [5] is an established TinyOS extension which enforces memory safety at runtime. It checks e.g.…”

Deriving State Machines from TinyOS Programs Using Symbolic Execution

“…The second has been to develop run-time monitoring (e.g., Sympathy [27]) and debugging tools (e.g., Nucleus [30], Clairvoyant [32]) that can simplify the process of discovering program errors. The third has been to develop compiletime program analysis tools [28,9,8] for catching program errors before execution.…”