1. 1 Efficient Memory Safety for TinyOS 2.1 Yang Chen Nathan Cooprider Will Archer Eric Eide David Gay † John Regehr University of Utah School of Computing † Intel Research Berkeley

2. 2 ● What happened? – State got corrupted – Hard to debug ● Limited visibility into executing systems ● Difficult to replicate complex bugs Suppose we have a WSN…

3. 3 Goal ● Catch all pointer and array bounds errors – Before they corrupt state ● Provide a choice of recovery action ● Put WSN software development on a solid foundation

4. 4 Expand into system safety Our contribution: Safe TinyOS Deputy: existing solution for making C safe Practical for deployment

5. 5 Example builds $ make mica2 $ make mica2 safe

6. 6 Language safety ● Deputy is the starting point – Safe C dialect developed at Berkeley – Annotations exploit values present in code to specify bounds/etc information – Translates a C program into a safe C program by inserting safety checks Language safety Deputy System safety Safe TinyOS Our work

7. 7 Compress error messages run modified nesC compiler enforce safety using Deputy compress error messages ● Deputy’s verbose messages – Use precious memory – No screen on the mote ● Replaced with integer ID – Fault location identifiers, FLIDs – FLIDs blinked on LEDs or sent to network 0x0773 tos/chips/cc2420/CC2420ReceiveP.nc: 241: CC2420ReceiveP$receiveDone_task$runTask: Assertion failed in upper bound coercion: CC2420ReceiveP$m_p_rx_buf->data + length <= CC2420ReceiveP$m_p_rx_buf + 28 decode FLID

8. 8 Safe TinyOS toolchain run modified nesC compiler enforce safety using Deputy compress error messages Annotate Safe TinyOS code TinyOS code run modified nesC compiler enforce safety using Deputy compress error messages Safe TinyOS app Modify TinyOS to work with Deputy Reduce overhead

9. 9 Resource usage ● Six TinyOS 2 benchmarks – 3,561 to 25,773 lines of C code ● No RAM usage increase – Deputy exploits existing bounds info. – Optimizer saves a little RAM

10. 10 On to bug hunting ● Ran Safe TinyOS applications on motes ● Found four bugs ● Will talk about three of them

11. 11 A bug Buffer length Serial Dispatcher ● Serial stack – passed in a buffer – Passes along one byte at a time ● Problem: given buffer length too large ● Out-of-bounds index for buffer Safety violation caught by Safe TinyOS Reported to TinyOS 2 maintainers and FIXED

12. 12 Another bug ● Active Message Queue – Scheduling of network link ● Queue moves on to next client on send done event ● With no clients – Spurious report of completion – Invalid array index ● Difficult to replicate – Several minutes, many nodes Send done Safety violation caught by Safe TinyOS 0 Current Send done Send done 123 Reported to TinyOS 2 maintainers and FIXED

13. 13 Yet another bug ● Time synchronization and leader election ● Array out-of-bounds access ● Difficult to locate – After 20 minutes – In “third-party” networking code for (i = 0; i < NUM_BUFFERS; i++) { if (m_pool[i].msg == NULL) break; } if (m_pool[i].msg == NULL) { m_pool[i].msg = _msg; } i can point to one past end of buffer Upon discovery Bug already fixed in latest release of third-party component

14. 14 Increased availability Array Out-of-bounds Array Out-of-bounds Reboot Normal TinyOS Safe TinyOS Rebuild Soft state Normal TinyOS: 0% average availability Safe TinyOS: 95% average availability

15. 15 Current Status ● Incorporating our changes into TinyOS ● Next steps – Support more platforms – Integrate Safe TinyOS with a stack depth analysis tool to avoid unsafety through stack overflow – Solve the problem of unsafe accesses to pointers to dead stack frames – Make safe execution the default for TinyOS applications

16. 16 Conclusion ● Type and memory safety is practical for tiny embedded systems – Safety for entire system – Low run-time cost compared to original unsafe applications – Can easily fit into existing programming practice http://www.cs.utah.edu/~coop/safetinyos/