TinyOS论文05：Efficient Memory Safety for TinyOS

1、论文主要提出了Safety TinyOS的概念，Safety TinyOS 主要是对TinyOS的一个优化来保证TinyOS中的类型安全和内存安全
2、类型安全指的是类型不会被混淆，例如把一个整型当成指针类型 + 内存安全：例如数据越界

3、Safety TinyOS涉及到的一个编译器和优化器
①、编译器-Deputy：通过注解为传感网程序插入相应的验证代码（类似于Java中的泛型，只是Deputy验证的是变量取值范围）。
②、cXprop一种基于数据流分析的C程序的静态分析器和优化器。
4、因为要往成程序中添加注解啊、修改源码的开销比较。

Abstract

1. 创建可靠地传感器网络程序很难：并发 + 分布 + 没有保护的硬件内存 + 资源受限 + 低级的编程语言；
2. 论文为TinyOS应用程序提供了有效的内存安全和类型安全(Safety TinyOS)，以此来编写更健壮的传感网程序。安全执行保证了在RAM崩溃之前捕获数组和指针错误。
3. 论文的贡献：
   1、在资源有限的情况下实现了程序的安全执行；
   2、能安全执行中断驱动并发的情况；
   3、扩展了NesC语言和编译器来支持安全的注解；
   4、找出TinyOS中的bug；
   5、在内存错误没有被修护的情况下能增加传感网程序的性能。

一、Introduce

1. 传感网程序中:空指针异常、数组越界访问、联合类型的误用这些问题很常见。
   以下为常见的两个场景：
   场景1：在故障节点上的内存安全错误很容易损坏RAM，而且很难查找这个bug。例如空指针异常：

struct { char x[28]; int y; } *p;
...
p = NULL;
...
p->y = z;

场景2：内存错误发生之前被检测到之后的处理：在发送数据之前重启或者关闭节点。
4. 现有的传感网程序都有第一个场景的问题，论文的研究室通过传感网程序的安全执行来实现第二个场景。实现过程会遇到的三个问题：
1、使得现有的程序安全而不是重新编写TinyOS代码；
2、实现必须简单；
3、开销小。
5. 安全执行的传感网结点称为安全的TinyOS，safe TinyOS包括类型安全和内存安全。
1、类型安全：类型不会被混淆，例如把一个整型当成指针类型；
2、内存安全：例如数据越界。

1. safe TinyOS在运行时向应用程序插入的代码来保证安全，当程序执行出现了错误，插入到程序中的代码就会替代错误代码。
2. safe TinyOS工具链采用的是cXprop——对嵌入式C代码的静态分析器(优化NesC语言的代价小)。
3. 论文的两个贡献：
   1、Safe TinyOS的详细描述，即如何在有限的资源的提前下实现传感网程序的安全执行，
   2、展示Safe TinyOS是一个开发可靠传感网程序的方法。

二、Background

1、TinyOS
1. 组件 + NesC + GCC + 短周期 + 两级并发模型(任务 + 中断) + 比C语言更轻便 +线程的组件库 + 内置的竞争条件检测器 + 静态资源分配模型；

Deputy

1. Deputy是一个确保C程序类型安全和内存安全的源对源编译器。它实现的观点是：程序中必须要有保证安全的必要信息。
2. 例如TinyOS中消息接收事件：

// msg：指针指向单一的一条信息；
// payload：指向存储信息的指针
// len：payload存储消息的长度；
event message_t *receive(message_t *msg,
void *payload, uint8_t len);

1. Deputy为代码加上“类型注解信息”来验证程序的类型安全(有点类似于Java中的泛型)，修改后的代码为：

event message_t *SAFE receive(message_t *SAFE msg,
void *COUNT(len) payload, uint8_t len);

1. Deputy将输入程序转化为运行时的检查来保证类型注解能够在运行时得到检测。，例如如下两部分代码：
   1、receive事件用于处理消息数据 + 发送消息接收信号事件
   2、注解代码为Deputy处理后的代码：

typedef struct {
  int len;
  char buffer[36];
} message_t;

event ... receive(..., void *COUNT(len) payload,
uint8_t len) {
  int i = ...;
  if (i >= len) deputy_fail(); // 保证payload的访问不会越界。
  if (((char *)payload)[i])
  ...;
}
void dispatch(message_t *SAFE m) {
  if (m->len > 36) deputy_fail(); // 添加了对缓存大小的判断
  signal receive(m, m->buffer, m->len);
}

1. Deputy的两个优势：
   1、获得一个最小的内存需求
   2、Deputy允许安全的代码(经过Deputy处理后的代码)与可信的代码相互操作。
   可信的代码：没有Deputy运行时检测的现有的编译好的二进制代码或者是可能违反类型安全的C代码片段。

cXprop

1. cXprop是嵌入式C程序的静态分析器和优化器。其优化包括：“传播常量标准值和指针 + 删除无用的条件、变量、同步、间接值、参数和返回值。cXprop是一种数据流分析(与路径、上下文无关)。
2. cXprop分析方法是跟中值集和指针及抽象与中的数据流。例如x代表具体的一个值集{1,4,10}；指针集，与值集类似
3. cXprop跟踪的数据有：标量值、指针、结构体变量、数组和全局变量。
4. cXprop分析TinyOS程序的一个良好的优点是它能够很好的分析中断处理器和主程序之间的共享变量。做法就是：cXprop提供了一种静态分析通过利用中断处理器的流边界只需要添加到NesC原子部分的末尾即可。

三、Practical Safety for TinyOS Applications

1、安全的TinyOS工具链

1. unsafe TinyOS：nesC编译器——GCC编译器
2. Safe TinyOS：使用一个修改了nesC编译器来处理带注解的组件 + 实现的四个步骤为：
   1、通过执行Deputy编译器来添加安全检测；
   2、保证中断驱动并发的类型安全；
   3、压缩违反安全的诊断信息；
   4、使用cXprop优化代码。

2、在nesC语言中支持Deputy注解

1. Deputy注解在nesC源文件中，会有修改了的nesC编译器编译成相应的C代码。
2. 修改的后的nesC编译器来修改带有Deputy注解的nesC代码示例：对有所全局和他们使用的变量添加一个独特的前缀

// nesC module ‘Mod1’.
module Mod1 { }
implementation {
// Annotation using a structure field
struct strange {
int length;
void *COUNT(length + sizeof(struct strange))
data;
} s;
// Annotation using a module variable
int length;
uint8_t *COUNT(length) buffer;
}
// C code output by our modified nesC compiler.
struct Mod1$strange {
int length;
void *COUNT(length + sizeof(struct Mod1$strange))
data;
} Mod1$s;
int Mod1$length;
uint8_t *COUNT(Mod1$length) Mod1$buffer;

1. Deputy 注解是一种扩展的C语言宏定义。将注解重命名Deputy变量的时候往往会出错，解决方法是，只对规定范围内的变量进行重命名。

2、处理并发

1. Deputy的根据注解向TinyOS程序插入安全的代码使用与顺序执行，但不是适用于并发执行。为了在并发中也保证安全执行，必须对插入的检测代码添加原子性约束，但这效率不高。
2. 论文中的做法是：由于NesC程序的两级并发模型，inyOS程序大量访问的变量是具有原子性的，显然同步变量是具有原子性的 + 异步变量(中断处理器中的变量)：已经添加了明显的原子约束操作；
3. 当通过Deputy插入的检测代码涉及到非原子性操作的变量(即竞争变量)时，要明确地为竞争变量加锁。
4. 论文是这么做的：nesC编译器能够找到竞争的变量，但是不能很好地找到通过指针访问的竞争变量

3、违反安全属性的处理

1. 违反安全属性的NesC程序在运行时Deputy会打印相应的错误信息。但是有两个问题：
   1、存储这些错误信息耗内存资源；
   2、传感网平台缺乏输出这些信息的设备；
2. 解决方式为：编写了一个单独的工具，用小的正数(错误定位标识符)来替代详细的错误信息，在通过错误定位标志符与PC端上的详细错误映射文件来显示具体的错误。

4、整个程序的优化

1. 论文使用cXprop来优化代码(代码大小和运行时开销)，删除无用的或者死亡了的程序。
2. 其中cXprop优化数组的方式是，以前是对数组中每个元素有有精确的表示，但是开销大，数组数量大了反而不精确，后来知识表示这一个数组而已。

四、Safety TinyOS的开销

1、代码的注解和修改

1. 大部分修改的代码是TinyOS的源码，而不是应用程序的代码

2. 创建Safety TinyOS应用成所改变的代码量很少

3. 论文的两个例子程序：getPayload修改API和修改访问数据报头部和尾部
4. 结论：对TinyOS源码的修改来创建安全的TinyOS的改变很少

2、Safety TinyOS源码的开销

1. Safety TinyOS源码不会增加内存开销，会增加少量的ROM开销和CPU资源
   3、代码的大小
   4、数据的大小
   5、处理器的使用