Tock项目中的进程二进制头校验机制解析

背景介绍

在嵌入式操作系统Tock中，进程二进制对象创建时需要对TBF(Tock Binary Format)头进行有效性验证。这一验证过程包括对基础TBF头的检查以及校验和的验证。这一机制在动态进程加载实现中引发了一些技术讨论。

技术挑战

动态进程加载实现中，内核需要扫描闪存以发现现有的有效进程二进制文件，从而构建链表结构。这一步骤确保了新应用不会侵占已有进程的内存区域。在此过程中，内核需要区分应用二进制和填充区域。

根据TBF头的安全威胁模型，内核要求在写入应用二进制时，前8字节的头部信息不能被篡改。进程加载器实现已经确保了total_size要求的有效性，这使得校验和的验证变得不再必要。

技术讨论

在测试过程中发现，当头部前8字节指示为填充区域，而后续8字节(校验和部分)不匹配时，内核在头解析阶段会返回错误。这引发了关于校验和验证必要性的技术讨论：

1. 移除校验和完整性检查：认为在已经确保total_size有效性的情况下，可以简化验证流程
2. 更新威胁模型：建议将校验和完整性也纳入威胁模型要求

实现方案

经过技术讨论后，最终决定采用以下方案：

• 不再使用parse_tbf_header()方法
• 改为检查头部的切片数据来确定是否为有效应用
• 动态进程加载器现在可以无障碍地发现进程二进制文件

安全考量

Tock项目团队最终决定维持现状，即不强制要求有效的校验和。这一决定基于以下安全考量：

1. 威胁模型已经确保我们可以信任total_length值的正确性
2. 进程加载器实现已经提供了足够的安全保障
3. 简化验证流程不会降低系统安全性

技术影响

这一决策对系统的影响包括：

1. 提高了动态进程加载的效率
2. 简化了二进制验证流程
3. 保持了系统的安全边界
4. 需要进一步修复tockloader list相关的功能

结论

在嵌入式系统设计中，安全性和效率往往需要权衡。Tock项目通过这一技术决策，在保证系统安全性的前提下优化了进程加载流程，体现了嵌入式系统设计中实用主义的安全哲学。这一案例也为其他嵌入式系统开发者提供了有价值的设计参考。