Oxide计算机Hubris项目中STM32H7硬件随机数生成器的可靠性优化

在嵌入式系统开发中，硬件随机数生成器(RNG)是安全协议的基础组件。Oxide计算机公司的Hubris项目团队最近发现并解决了一个关于STM32H7微控制器内置RNG模块的重要可靠性问题，这个问题影响了系统的安全功能实现。

问题背景

在最近的一次生产构建中，技术人员尝试通过维护接口访问设备时遇到了安全协议失败的情况。系统日志显示，安全处理器(SP)无法创建ECDSA挑战，其根本原因是无法从RNG获取随机数nonce。深入分析发现，RNG驱动程序返回了"种子错误"(SeedError)，具体表现为状态寄存器中的SEIS(种子错误中断状态)标志被置位。

技术分析

STM32H7的RNG模块在运行过程中可能会遇到各种错误条件。根据芯片手册，当检测到以下情况时会触发SEIS标志：

1. 时钟错误
2. 种子值不符合要求
3. 其他影响随机数质量的异常情况

原始驱动程序实现简单地检测到SEIS标志就返回错误，没有尝试任何恢复措施。这在实际应用中可能导致系统在需要随机数时不可用，特别是在无人值守的设备中，如果所有维护接口都不可用，将无法通过简单重启来恢复功能。

解决方案

项目团队基于STM32H7参考手册中的建议，实现了完整的错误恢复流程：

1. 错误检测与恢复：当检测到SEIS标志时，驱动程序不再立即失败，而是执行手册规定的恢复步骤：

   • 清除SEIS标志
   • 重置RNG模块
   • 重新初始化种子

2. 渐进式填充策略：对于大缓冲区请求(如128字节)，驱动程序会尽可能多地填充有效随机数，只在连续遇到无法恢复的错误时才返回错误。

3. 错误报告增强：未来计划集成到系统的错误报告(e-report)设施中，SEIS事件将生成详细的错误报告。

实现细节

改进后的驱动程序逻辑流程如下：

1. 检查RNG状态寄存器
2. 如果SEIS置位：
   • 执行恢复流程
   • 记录错误事件
   • 继续尝试生成随机数
3. 只有在连续恢复失败后才返回错误
4. 尽可能填充请求的缓冲区，即使中间遇到可恢复的错误

这种设计确保了：

• 更高的系统可用性
• 更好的错误恢复能力
• 对上层应用更友好的接口行为

实际影响

这一改进显著提高了系统的可靠性，特别是在以下场景：

• 长时间运行的设备
• 恶劣电气环境下的设备
• 安全关键应用场景

通过软复位即可解决问题的情况现在可以通过驱动自动恢复，减少了对人工干预的需求。

结论

硬件随机数生成器的可靠性对嵌入式系统的安全性至关重要。Oxide团队通过深入理解STM32H7的RNG模块特性，实现了符合芯片设计规范且更加健壮的驱动程序，为Hubris项目的安全功能提供了更可靠的基础保障。这一改进也展示了在嵌入式系统开发中，深入理解硬件特性和遵循厂商建议的重要性。