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 ResearchBerkeley

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

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

Expand

into system safety

Our contribution: Safe TinyOS

Deputy: existing solution for making C safe

Practical fordeployment

5

Example builds

$ make mica2

$ make mica2 safe

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 TinyOSOur work

7

Compress error messages

run modifiednesC compiler

enforce safetyusing Deputy

compresserror 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

decodeFLID

8

Safe TinyOS toolchain

run modifiednesC compiler

enforce safetyusing Deputy

compresserror messages

AnnotateSafe

TinyOScode

TinyOScode

run modifiednesC compiler

enforce safetyusing Deputy

compresserror messages

Safe TinyOS

appModify TinyOS to work

with Deputy

Reduce overhead

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

On to bug hunting

● Ran Safe TinyOS applications on motes● Found four bugs● Will talk about three of them

11

A bug

Buffer length

SerialDispatche

r

● 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 violationcaught by

Safe TinyOSReporte

d to TinyOS 2

maintainers and

FIXED

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 violationcaught by

Safe TinyOS

0

Current

Send done

Send done

123Reporte

d to TinyOS 2

maintainers and

FIXED

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

Increased availability

Array Out-of-bounds

Array Out-of-bounds

Reboot

NormalTinyOS

SafeTinyOS

RebuildSoft state

Normal TinyOS:0% average availability

Safe TinyOS:95% average

availability

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

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/