1 TinyOS 2.1: Deploying Memory Safety Nathan Cooprider Yang Chen Will Archer Eric Eide David Gay † John Regehr University of Utah School of Computing † Intel Research Berkeley Follow-up to Safe TinyOS work published in SenSys ’07

2 A TinyOS application 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

3 Goal of Safe TinyOS ● 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 Include in TinyOS 2.1 main distribution

4 ● Annotations which “make sense” ● nesC annotation-aware ● Not affect unsafe compilation ● Only small increase in build time ● Only small increase in tool chain ● Maintain reduced resource use Include in TinyOS 2.1 main distribution

5 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

6 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

7 Conclusion ● Type and memory safety is practical for TinyOS deployment – Safety for entire system – Low run-time cost compared to original unsafe applications – Can easily fit into existing programming practice