在驱动程序开发使用静态分析工具.docxVIP

在驱动程序开发中使用静态分析工具 Adam Shapiro Senior Program Manager US-Networking Core PM 议程 静态分析工具 什么是静态分析？ 静态分析工具的优点 下一版Windows将有哪些更新？ PREfast for Drivers (PFD) 核心的PREfast代码注解(annotations) Static Driver Verifier (SDV) RoleTypes 总结 什么是静态分析? 源代码的编译期间分析 类似于代码走查, 但由工具来完成 一个简单的例子就是编译期间的类型检查 检查对定义完善的限制条件的违反 过程调用约定和API约定 由静态检查工具发现的代码错误示例 f()要求p不为NULL: 重复结束同一个IRP: IoCompleteRequest (Irp); ... IoCompleteRequest (Irp); p = NULL; … f(p); 为什么使用静态分析? 低级代码错误! 经验法则 “如果有一个缺陷在程序员的桌面上修正要花1美元，那么一旦这个缺陷已经被集成到完成的程序中，将需要100美元来修正，如果在软件被应用部署之后才发现这一缺陷，代价将达到数万美元。” “Building a Better Bug Trap” — The Economist June 2003 工具可以提高你的效率 按钮技术 100%的路径覆盖率 成本低(让计算机帮你做) 快速 (计算机在几分钟或几小时内完成几个星期的人力工作) 尽早发现缺陷 甚至在拿到硬件设备之前 在设计测试用例之前 在平常写代码的时候 缺陷报告容易使用 在源代码中直接给出缺陷路径（或者是关键点），降低调试代码的成本 静态分析如何工作？ 建立一个驱动的抽象模型，沿着所有路径完整检查执行代码 抽象模型更简单：被简化了… 简化到能够完整检查（模拟）的程度 跟驱动程序近似 控制部分保持一致 保留所有路径并同等对待 数据状态是近似的 如果参数x无约束条件, 假定一切值都是可能的。 如果(x0)在测试点是成立的, 维护布尔值(x0),而不是x的整数值：布尔值比整数值更简单 If (x 0) { IoCompleteRequest (Irp); } 静态检查工具不是银弹 不是替代功能测试 针对违反定义良好的约束条件 局限性 不可能知道所有会发生错误 算法是基于源代码的抽象和启发 结果可能是错误的肯定和错误否定 是个好用的工具 静态分析工具比较 PREfast for Drivers Static Driver Verifier 驱动模型 任意 WDM KMDF NDIS 语言 C和C++ 只支持C 发现的问题 本地的缺陷 易于修正 大规模 全局的缺陷 难以修正 小规模 范围 进程级 本地的违例 进程间 发现深层错误 开发周期 早期使用: “编译驱动的时候” 运行仅需几分钟，所以请经常运行 后期使用: “驱动基本结构成形的时候” 定期运行, 修正错误后运行 KMDF验证平均需时 = 20 min WDM验证平均需时= 40 min 两种静态分析工具并用 WDK中提供的两种互补技术 PREfast for Drivers: 在每个进程中深度分析可能的违例 Static Driver Verifier: 延执行路径，跨进程间的边界 ReadFoo ( PIRP Irp ) { ... status = Bar (Irp); if (status) { IoCompleteRequest(Irp); } } Bar ( PIRP Irp ) { ... IoCompleteRequest(Irp); return STATUS_SUCCESS; } 两种静态分析工具并用示例 ReadFoo ( PIRP Irp ) { PIRP p = NULL; ... if (status) { IoCompleteRequest(p); } } PFD有什么更新？ 微软内部推动 “PFD Clean” Windows 7 – Microsoft拥有的内置驱动和WDK范例完全通过PFD 微软的驱动和WDK的公共头文件都有注解 内部引擎的改进 表达式的范围更广 支持常量, 成员名字, 无副作用的C表达式 更好的注解错误检查 WDK中包含部分微软自动代码检查(OACR) SDV有什么更新 内置驱动和 WDK KMDF, WDM范例通过SDV 针对NDIS的SDV – 和NDIS组无缝的合作 为NDIS驱动新增39个新规则 针对WDM和KMDF的扩展规则集 可靠性, 安全性, IRQL, 同步, 正确的对象创建规则