1. Software Dynamic Translators on Wireless Sensor Networks: Challenges, Approaches, and Tradeoffs Jing Yang, Apala Guha, Kim Hazelwood, Mary Lou Soffa, and Kamin Whitehouse Department of Computer Science, School of Engineering and Applied Science, University of Virginia Software Dynamic Translators on Wireless Sensor Networks: Challenges, Approaches, and Tradeoffs Jing Yang, Apala Guha, Kim Hazelwood, Mary Lou Soffa, and Kamin Whitehouse Department of Computer Science, School of Engineering and Applied Science, University of Virginia Motivations: In recent years, wireless sensor networks have transitioned from the research arena to various real-world applications, including detecting vibrations on the Golden Gate Bridge, tracking zebras in their natural habitat, and monitoring immigration across the southern border of the United States. A wireless sensor network is a collection of tiny, wireless, and spatially distributed devices that cooperatively monitor physical or environmental conditions. Sensor nodes are often battery-powered and are deployed in remote, hard-to-reach locations, which may need to live for years and are difficult to access physically if problems occur. This characteristic makes the development cycle difficult because the hard-to-reach sensor nodes cannot be tested or debugged in the true environment, and software updates that are now commonplace every few days in the desktop environment are difficult and expensive to apply. Furthermore, It is also crucial that wireless sensor networks own high reliability and survivability even when deployed in hostile territories, for example, enforced memory and I/O protections for privileged execution. Lastly, performance analysis supports are widely needed, such as execution profiling. In order to advance to the next stage, wireless sensor networks must meet the aforementioned challenges. An exciting approach to solve these problems is through the use of software dynamic translators. Providing the capability to modify the program incrementally based on user requirements, we can achieve in-situ debugging and dynamic reprogramming by sending queries to those target sensor nodes, making them trap execution at program memory of address 0x40 or turn the instruction at that location to a nop. Similarly, software dynamic translators can also monitor execution across protection boundaries to prevent many security attacks and instrument the program to collect execution statistics, which have been proven very useful in the desktop environment [5, 6, 8]. Motivations: In recent years, wireless sensor networks have transitioned from the research arena to various real-world applications, including detecting vibrations on the Golden Gate Bridge, tracking zebras in their natural habitat, and monitoring immigration across the southern border of the United States. A wireless sensor network is a collection of tiny, wireless, and spatially distributed devices that cooperatively monitor physical or environmental conditions. Sensor nodes are often battery-powered and are deployed in remote, hard-to-reach locations, which may need to live for years and are difficult to access physically if problems occur. This characteristic makes the development cycle difficult because the hard-to-reach sensor nodes cannot be tested or debugged in the true environment, and software updates that are now commonplace every few days in the desktop environment are difficult and expensive to apply. Furthermore, It is also crucial that wireless sensor networks own high reliability and survivability even when deployed in hostile territories, for example, enforced memory and I/O protections for privileged execution. Lastly, performance analysis supports are widely needed, such as execution profiling. In order to advance to the next stage, wireless sensor networks must meet the aforementioned challenges. An exciting approach to solve these problems is through the use of software dynamic translators. Providing the capability to modify the program incrementally based on user requirements, we can achieve in-situ debugging and dynamic reprogramming by sending queries to those target sensor nodes, making them trap execution at program memory of address 0x40 or turn the instruction at that location to a nop. Similarly, software dynamic translators can also monitor execution across protection boundaries to prevent many security attacks and instrument the program to collect execution statistics, which have been proven very useful in the desktop environment [5, 6, 8]. Background: There are generally two categories of software dynamic translators based on different techniques to achieve program modification, whose architectures are depicted in Figure 1. Translation-based software dynamic translators use a just-in-time compiler to convert binary code into small code segments that are stored in the code cache for efficiency. During this compilation process, the translator transforms the code in several different ways: in can optimize the code, convert it to a different instruction set architecture, or add instrumentation code to perform operations whenever a specific code point is reached. Instrumentation code (i.e., payloads) can be useful, for example, to count the number of times each function is executed. Payloads can be integrated directly into code segments in the code cache, or as shown in the figure, smaller probes can be inserted in the code cache, which point to payloads that are stored separately. Therefore, translation-based software dynamic translators can provide dense, fine-grained program modification, but suffers from larger execution overhead if modification requirements change frequently. Injection-based software dynamic translators modify the program by rewriting the binary code at key locations to insert probes, which invoke payloads that contain instrumentation code. For example, a probe can be inserted at the beginning of a function to count the number of times this function is executed. These payloads may then invoke the code injector to inject probes into other locations in the binary code, as depicted by the figure. Therefore, injection-based software dynamic translators are suitable for applications that need sparse but frequently changed program modification, such as in-situ debugging. Background: There are generally two categories of software dynamic translators based on different techniques to achieve program modification, whose architectures are depicted in Figure 1. Translation-based software dynamic translators use a just-in-time compiler to convert binary code into small code segments that are stored in the code cache for efficiency. During this compilation process, the translator transforms the code in several different ways: in can optimize the code, convert it to a different instruction set architecture, or add instrumentation code to perform operations whenever a specific code point is reached. Instrumentation code (i.e., payloads) can be useful, for example, to count the number of times each function is executed. Payloads can be integrated directly into code segments in the code cache, or as shown in the figure, smaller probes can be inserted in the code cache, which point to payloads that are stored separately. Therefore, translation-based software dynamic translators can provide dense, fine-grained program modification, but suffers from larger execution overhead if modification requirements change frequently. Injection-based software dynamic translators modify the program by rewriting the binary code at key locations to insert probes, which invoke payloads that contain instrumentation code. For example, a probe can be inserted at the beginning of a function to count the number of times this function is executed. These payloads may then invoke the code injector to inject probes into other locations in the binary code, as depicted by the figure. Therefore, injection-based software dynamic translators are suitable for applications that need sparse but frequently changed program modification, such as in-situ debugging. Challenges: Three major challenges exist to implement software dynamic translators on wireless sensor networks. First of all, sensor nodes are often extremely memory constrained. For example, the Mica2 Berkeley motes only has 128 KB program memory and 4 KB data memory [1]. A large memory footprint can prohibit the software dynamic translator from running on the sensor node, or at least restrict the size of workable programs. Secondly, unlike in the desktop and laptop markets, the microcontrollers adopted by most sensor nodes often use flash- based program memory which has a limited life time. For example, on the Mica2 Berkeley Motes, each block of program memory only has 10,000 write/erase cycles [1]. Though software dynamic translators inherently have to modify the program memory, a heavy workload may prevent them from practical use. Finally, most sensor nodes have CPU idle rates of over 99% so that slow down caused by translation is usually not important. However, sensor nodes are also very I/O intensive, and I/O is very timing sensitive. For example, the CC1000 radio chip used by the Mica2 Berkeley motes triggers an interrupt to the microcontroller every 416 us, which cannot be missed in order to maintain correct behaviors [1]. It is therefore critical that software dynamic translators identify code that is dealing with timing-sensitive I/O and prepare it in advance before actual use. Challenges: Three major challenges exist to implement software dynamic translators on wireless sensor networks. First of all, sensor nodes are often extremely memory constrained. For example, the Mica2 Berkeley motes only has 128 KB program memory and 4 KB data memory [1]. A large memory footprint can prohibit the software dynamic translator from running on the sensor node, or at least restrict the size of workable programs. Secondly, unlike in the desktop and laptop markets, the microcontrollers adopted by most sensor nodes often use flash- based program memory which has a limited life time. For example, on the Mica2 Berkeley Motes, each block of program memory only has 10,000 write/erase cycles [1]. Though software dynamic translators inherently have to modify the program memory, a heavy workload may prevent them from practical use. Finally, most sensor nodes have CPU idle rates of over 99% so that slow down caused by translation is usually not important. However, sensor nodes are also very I/O intensive, and I/O is very timing sensitive. For example, the CC1000 radio chip used by the Mica2 Berkeley motes triggers an interrupt to the microcontroller every 416 us, which cannot be missed in order to maintain correct behaviors [1]. It is therefore critical that software dynamic translators identify code that is dealing with timing-sensitive I/O and prepare it in advance before actual use. (b) Injection-based SDT Hardware Modified Program Payload SDT Payload SDT (a) Translation-based SDT Hardware Original Program Modified Program Traces Payload SDT Payload ReadWrite Code Cache Figure 1. Two categories of software dynamic translators based on different techniques to achieve program modification Implementations: We have implemented two prototype software dynamic translators on the Mica2 Berkeley Motes. The first one is an injection-based source-level debugger while the other one is a raw translation-based software dynamic translator which produces dynamic basic blocks of the program but does not apply any extra modification. Table 1 lists the data memory and program memory consumed by each software dynamic translator and that of the Mica2 Berkeley Motes. On Other platforms, however, things can become quite different. For example, the telosb sensor nodes have 10 KB data memory but only own 48 KB program memory, which makes our current implementations hardly practical since in some cases only one fourth of the program memory is left to load the program [2]. Implementations: We have implemented two prototype software dynamic translators on the Mica2 Berkeley Motes. The first one is an injection-based source-level debugger while the other one is a raw translation-based software dynamic translator which produces dynamic basic blocks of the program but does not apply any extra modification. Table 1 lists the data memory and program memory consumed by each software dynamic translator and that of the Mica2 Berkeley Motes. On Other platforms, however, things can become quite different. For example, the telosb sensor nodes have 10 KB data memory but only own 48 KB program memory, which makes our current implementations hardly practical since in some cases only one fourth of the program memory is left to load the program [2]. Data MemoryProgram Memory Mica24,096 Bytes131,072 Bytes Injection-based source-level debugger 876 Bytes31,360 Bytes Raw translation-based software dynamic translator 405 Bytes17,464 Bytes Table 1. Data and program memory required by two software dynamic translators Tradeoffs: In the implementation of the source-level debugger, we need to leverage the following tradeoffs:  Data and program memory vs. execution speed  Clock consistency vs. execution speed  Data and program memory vs. number of radio messages  Data and program memory vs. number of flash writes  Data memory vs. program memory Figure 2 illustrates the evaluation of inserting a conditional breakpoint in terms of six metrics: execution overhead, number of radio messages, number of flash writes, data memory consumption, program memory consumption, and number of skewed clock cycles. Tradeoffs: In the implementation of the source-level debugger, we need to leverage the following tradeoffs:  Data and program memory vs. execution speed  Clock consistency vs. execution speed  Data and program memory vs. number of radio messages  Data and program memory vs. number of flash writes  Data memory vs. program memory Figure 2 illustrates the evaluation of inserting a conditional breakpoint in terms of six metrics: execution overhead, number of radio messages, number of flash writes, data memory consumption, program memory consumption, and number of skewed clock cycles. Future Works: We consider the following future works: (1) Study interpretation-based software dynamic translators. (2) Study the merits and disadvantages of different categories of software dynamic translators and map each category to a suitable series of meta-execution applications. (3) Further exploit innovative approaches to reduce memory consumption, reduce number of flash writes, and handle timing-sensitive code. (4) Develop advanced multi-hop wireless routing protocols to facilitate more efficient and flexible client-server communications. (5) Integrate software dynamic translation techniques to existing operating systems, such as [3, 4, 7]. Future Works: We consider the following future works: (1) Study interpretation-based software dynamic translators. (2) Study the merits and disadvantages of different categories of software dynamic translators and map each category to a suitable series of meta-execution applications. (3) Further exploit innovative approaches to reduce memory consumption, reduce number of flash writes, and handle timing-sensitive code. (4) Develop advanced multi-hop wireless routing protocols to facilitate more efficient and flexible client-server communications. (5) Integrate software dynamic translation techniques to existing operating systems, such as [3, 4, 7]. References: [1] Atmel Corporation. Atmega128L Specifications. http://www.atmel.com/dyn/products/product_card.asp?part_id=2018. [2] Jan Beutel. Metrics for sensor network platforms. In Proceedings of ACM Workshop on Real-World Wireless Sensor Networks, 2006. [3] Shah Bhatti, James Carlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker, Charles Gruenwald, Adam Torgerson, Richard Ham. MANTIS OS: an embedded multithreaded operating system for wireless micro sensor platforms. ACM/Kluwer Mobile Networks and Applications, Special Issue on Wireless Sensor Networks, 10(4) 2005. [4] Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler, and Mani Srivastava. A dynamic operating system for sensor nodes. In Proceedings of International Conference on Mobile Systems, Applications, and Services, 2005. [5] Chi-Keung Luk, Robert Cohen, Robert Muth, Harish Patil, Artur Klauser, Geoff Lowney, Steven Wallace, Vijay Janapareddi, and Kim Hazelwood. Pin: building customized program analysis tools with dynamic instrumentation. In Proceedings of ACM Conference on Programming Language Design and Implementation, 2005. [6] Vladimir Kiriansky, Derek Bruening, and Saman Amarasinghe. Secure execution via program shepherding. In Proceedings of USENIX Security Symposium, 2002. [7] Philip Levis, Sam Madden, Joseph Polastre, Robert Szewczyk, Kamin Whitehouse, Alec Woo, David Gay, Jason Hill, Matt Welsh, Eric Brewer, and David Culler. TinyOS: an operating system for wireless sensor networks. Ambient Intelligence, 2004. [8] Nicholas Nethercote and Julian Seward. Valgrind: a program supervision framework. Electronics Notes in Theoretical Computer Science, 89(2), 2003.References: [1] Atmel Corporation. Atmega128L Specifications. http://www.atmel.com/dyn/products/product_card.asp?part_id=2018. [2] Jan Beutel. Metrics for sensor network platforms. In Proceedings of ACM Workshop on Real-World Wireless Sensor Networks, 2006. [3] Shah Bhatti, James Carlson, Hui Dai, Jing Deng, Jeff Rose, Anmol Sheth, Brian Shucker, Charles Gruenwald, Adam Torgerson, Richard Ham. MANTIS OS: an embedded multithreaded operating system for wireless micro sensor platforms. ACM/Kluwer Mobile Networks and Applications, Special Issue on Wireless Sensor Networks, 10(4) 2005. [4] Chih-Chieh Han, Ram Kumar, Roy Shea, Eddie Kohler, and Mani Srivastava. A dynamic operating system for sensor nodes. In Proceedings of International Conference on Mobile Systems, Applications, and Services, 2005. [5] Chi-Keung Luk, Robert Cohen, Robert Muth, Harish Patil, Artur Klauser, Geoff Lowney, Steven Wallace, Vijay Janapareddi, and Kim Hazelwood. Pin: building customized program analysis tools with dynamic instrumentation. In Proceedings of ACM Conference on Programming Language Design and Implementation, 2005. [6] Vladimir Kiriansky, Derek Bruening, and Saman Amarasinghe. Secure execution via program shepherding. In Proceedings of USENIX Security Symposium, 2002. [7] Philip Levis, Sam Madden, Joseph Polastre, Robert Szewczyk, Kamin Whitehouse, Alec Woo, David Gay, Jason Hill, Matt Welsh, Eric Brewer, and David Culler. TinyOS: an operating system for wireless sensor networks. Ambient Intelligence, 2004. [8] Nicholas Nethercote and Julian Seward. Valgrind: a program supervision framework. Electronics Notes in Theoretical Computer Science, 89(2), 2003. Approaches: Table 2 lists the approaches we used in translation- and injection-based software dynamic translators in order to reduce memory consumption, reduce number of flash writes, and handle timing-sensitive code. Basically the same idea can be shared in both cases except that translation-based software dynamic translators adopt code caches which may dramatically increase the program memory consumption. Though reducing translation granularity and using multilevel code caches can alleviate the problem, these techniques increase the number of flash writes due to frequent fetches and evictions of code segments. We need to exploit different tradeoffs based on different sensor node platforms. Approaches: Table 2 lists the approaches we used in translation- and injection-based software dynamic translators in order to reduce memory consumption, reduce number of flash writes, and handle timing-sensitive code. Basically the same idea can be shared in both cases except that translation-based software dynamic translators adopt code caches which may dramatically increase the program memory consumption. Though reducing translation granularity and using multilevel code caches can alleviate the problem, these techniques increase the number of flash writes due to frequent fetches and evictions of code segments. We need to exploit different tradeoffs based on different sensor node platforms. Reduce memory consumptionReduce number of flash writs Handle timing-sensitive code Translation-based software dynamic translator (1) Reduce translation granularity (2) Create multilevel code caches using external memory (3) Use client-server model (1) Increase translation granularity (2) Choose fetch and eviction policies based on block- writable feature (1) Pre-insert probes in I/O code (2) Speed context switch Injection-based software dynamic translator (1) Keep one copy of context switch code (2) Use client-server model (1) Avoid probe reinsertion (1) Pre-translate and pin I/O code in code cache (2) Speed context switch (3) Fetch from neighbors Table 2. Approaches used by translation- and injection-based software dynamic translators in order to reduce memory consumption, reduce number of flash writes, and handle timing-sensitive code Execution Overhead # Radio Messages # Flash Writes Data Memory Program Memory # Skewed Clock Cycles Classical GDB Remote Debugging Shared Trampoline + GDB Remote Protocol 962 ms 4 0 8 256 0 962 ms 44 8 00 Shared Trampoline + Functionality Moving 186 ms 0 4 26 00 Faster context switch + Functionality Moving 27 cc 0 0 21 256 27 Figure 2. Evaluation of inserting a conditional breakpoint using the source-level debugger