Efficient memory safety for TinyOS

ManuscriptReliable 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

Poster abstract: TinyOS 2.1 adding threads and memory protection to tinyOS

ManuscriptThe release of TinyOS 2.0 two years ago was motivated by the need for greater platform flexibility, improved robustness and reliability, and a move towards service oriented application development. Since this time, we have seen the community embrace these efforts and add support for additional hardware platforms (TinyNode, Iris, Shimmer, BtNode, IntelMote2), and new application level services (CTP[4], Deluge 2.0[3], FTSP[9], ICEM[5], printf, TYMO, DIP[8], DRIP[7], ...). These enhancements are important in the progression of TinyOS as a whole, and have resulted in several minor releases (i.e. TinyOS 2.0.1, 2.0.2). TinyOS 2.1 is the next stage in the evolution of TinyOS; it takes a step towards addressing the need for easier and more robust application development. TinyOS 2.1 introduces a number of significant enhancements to core TinyOS components and interfaces. The most notable features include a fully preemptable application-level threads library known as TOSThreads, and a runtime memory protection service called Safe TinyOS. The former aims to ease writing event-driven code while preserving the time-sensitive aspect of TinyOS. The latter aims to make applications more robust through memory safety checks

Secure Modules in TinyOS

© ASEE 2015In this paper, we discuss TinyOS as a flexible operating system that is suitable for wireless sensor networks. It is a powerful tool that is capable of forming a strong component of intelligent systems. Similarly, sensor networks are composed of accurate, low levels of power nodes that carry out simultaneous, reactive programs that operate within the limitations of power and memory. As a solution, we integrate components of the TinyOS with TinyHash or modules for better operations. We also present more data about four components based on our proposed protocol, which includes hash function, module hash table, base station, and algorithm chart

Application Memory Isolation on Ultra-Low-Power Mcus

The proliferation of applications that handle sensitive user data on wearable platforms generates a critical need for embedded systems that offer strong security without sacrificing flexibility and long battery life. To secure sensitive information, such as health data, ultra-low-power wearables must isolate applications from each other and protect the underlying system from errant or malicious application code. These platforms typically use microcontrollers that lack sophisticated Memory Management Units (MMU). Some include a Memory Protection Unit (MPU), but current MPUs are inadequate to the task, leading platform developers to software-based memory-protection solutions. In this paper, we present our memory isolation technique, which leverages compiler inserted code and MPU-hardware support to achieve better runtime performance than software-only counterparts

Operating systems for wireless sensor networks: A survey

This paper presents a survey on the current state-of-the-art in Wireless Sensor Network (WSN) Operating Systems (OSs). In recent years, WSNs have received tremendous attention in the research community, with applications in battlefields, industrial process monitoring, home automation, and environmental monitoring, to name but a few. A WSN is a highly dynamic network because nodes die due to severe environmental conditions and battery power depletion. Furthermore, a WSN is composed of miniaturized motes equipped with scarce resources e.g., limited memory and computational abilities. WSNs invariably operate in an unattended mode and in many scenarios it is impossible to replace sensor motes after deployment, therefore a fundamental objective is to optimize the sensor motes' life time. These characteristics of WSNs impose additional challenges on OS design for WSN, and consequently, OS design for WSN deviates from traditional OS design. The purpose of this survey is to highlight major concerns pertaining to OS design in WSNs and to point out strengths and weaknesses of contemporary OSs for WSNs, keeping in mind the requirements of emerging WSN applications. The state-of-the-art in operating systems for WSNs has been examined in terms of the OS Architecture, Programming Model, Scheduling, Memory Management and Protection, Communication Protocols, Resource Sharing, Support for Real-Time Applications, and additional features. These features are surveyed for both real-time and non-real-time WSN operating systems

Amulet: An Energy-Efficient, Multi-Application Wearable Platform

Wearable technology enables a range of exciting new applications in health, commerce, and beyond. For many important applications, wearables must have battery life measured in weeks or months, not hours and days as in most current devices. Our vision of wearable platforms aims for long battery life but with the flexibility and security to support multiple applications. To achieve long battery life with a workload comprising apps from multiple developers, these platforms must have robust mechanisms for app isolation and developer tools for optimizing resource usage.\r\n\r\nWe introduce the Amulet Platform for constrained wearable devices, which includes an ultra-low-power hardware architecture and a companion software framework, including a highly efficient event-driven programming model, low-power operating system, and developer tools for profiling ultra-low-power applications at compile time. We present the design and evaluation of our prototype Amulet hardware and software, and show how the framework enables developers to write energy-efficient applications. Our prototype has battery lifetime lasting weeks or even months, depending on the application, and our interactive resource-profiling tool predicts battery lifetime within 6-10% of the measured lifetime

Lazy Preemption to Enable Path-Based Analysis of Interrupt-Driven Code

ABSTRACT One of the important factors in ensuring the correct functionality of wireless sensor networks (WSNs) is the reliability of the software running on individual sensor nodes. Research has shown that path-sensitive static analysis is effective for bug detection and fault diagnosis; however, path-sensitive analysis is prohibitively expensive when applied to a WSN application due to the large state space caused by arbitrary interrupt preemptions. In this paper, we propose a new execution model called lazy preemption that reduces this state space by restricting interrupt handlers to a set of predetermined preemption points, if possible. This execution model allows us to represent the program with an inter-interrupt control flow graph (IICFG), which is easier to analyze than the original CFGs with arbitrary interrupt preemptions

Surviving sensor network software faults

We describe Neutron, a version of the TinyOS operating system that efficiently recovers from memory safety bugs. Where existing schemes reboot an entire node on an error, Neutron’s compiler and runtime extensions divide programs into recovery units and reboot only the faulting unit. The TinyOS kernel itself is a recovery unit: a kernel safety violation appears to applications as the processor being unavailable for 10–20 milliseconds. Neutron further minimizes safety violation cost by supporting “precious ” state that persists across reboots. Application data, time synchronization state, and routing tables can all be declared as pre-cious. Neutron’s reboot sequence conservatively checks that pre-cious state is not the source of a fault before preserving it. Together, recovery units and precious state allow Neutron to reduce a safety violation’s cost to time synchronization by 94 % and to a routing protocol by 99.5%. Neutron also protects applications from losing data. Neutron provides this recovery on the very limited resources of a tiny, low-power microcontroller

Surviving sensor network software faults

ManuscriptWe describe Neutron, a version of the TinyOS operating system that efficiently recovers from memory safety bugs. Where existing schemes reboot an entire node on an error, Neutron's compiler and runtime extensions divide programs into recovery units and reboot only the faulting unit. The TinyOS kernel itself is a recovery unit: a kernel safety violation appears to applications as the processor being unavailable for 10-20 milliseconds. Neutron further minimizes safety violation cost by supporting "precious" state that persists across reboots. Application data, time synchronization state, and routing tables can all be declared as precious. Neutron's reboot sequence conservatively checks that precious state is not the source of a fault before preserving it. Together, recovery units and precious state allow Neutron to reduce a safety violation's cost to time synchronization by 94% and to a routing protocol by 99:5%. Neutron also protects applications from losing data. Neutron provides this recovery on the very limited resources of a tiny, low-power microcontroller