OpenTitan项目中DICE证书创建过程中的潜在启动循环问题分析

问题背景

在OpenTitan项目的earlgrey_1.0.0版本芯片中，发现了一个与安全启动相关的严重问题。该问题表现为芯片在某些情况下会陷入启动循环(boot-loop)，导致设备无法正常启动。经过深入调查，发现问题根源在于DICE(Device Identifier Composition Engine)证书创建过程中的异常处理机制存在缺陷。

问题现象

工程师在实际部署中观察到了两种不同的异常表现：

1. ROM层启动循环：表面上看是ROM层的启动循环，实际上是由于不可变区段(immutable section)配置不当导致的。芯片报告的错误代码为02495202(非法指令)。

2. ROM_EXT层启动循环：在ROM_EXT层出现的启动循环，芯片尝试启动所有者固件后报告错误代码0050540d(kErrorPersoTlvInternal)。

根本原因分析

通过对闪存内容的检查，发现问题的直接原因是DiceCerts信息页被擦除或部分编程。具体分析如下：

1. 证书解析容错性不足：perso_tlv_get_cert_obj函数在遇到闪存页被擦除或部分编程时，会返回kErrorPersoTlvInternal错误。当前实现中，当检测到长度值为0xFFF(全1)时，会认为数据过长而报错。

2. 错误处理策略不当：dice_chain_load_cert_obj函数对错误的处理不够灵活，没有将perso_tlv_get_cert_obj的所有错误都视为"未找到"情况处理。

3. 完整性校验缺失：与BootData和OwnerPage页面不同，DiceCerts页面缺少完整性校验机制(如SHA256或KMAC)。当设备在写入证书页面时意外重启，会导致页面数据不完整或损坏。

技术影响

在观察到的第二种情况中，设备出现了部分CDI_0证书损坏的情况。由于当前实现中没有对CDI证书进行完整验证(出于性能考虑)，如果仅修复CDI_1证书而CDI_0证书保持损坏状态，问题将持续存在直到ROM_EXT更新。

对于UDS证书页面，情况更为复杂，因为UDS证书是在制造过程中创建并注入的，无法在设备端重新生成。当前已经存在一些没有完整性校验方案的芯片。

解决方案

针对这一问题，OpenTitan团队提出了以下改进措施：

1. 增强错误恢复能力：改进dice_chain_load_cert_obj函数的容错性，使其能够更合理地处理各种错误情况。

2. 引入完整性校验：为证书页面添加完整性校验机制(如SHA256)，确保数据完整性。

3. CDI页面处理优化：在加载CDI页面时先验证完整性，如果校验失败则重新生成两个CDI证书。

4. UDS页面处理优化：在加载UDS页面时检查完整性，但仅标记校验失败而不尝试修复(因为无法重新生成)。

5. 测试增强：考虑创建损坏证书页面的测试用例，提高测试覆盖率。

总结

这一问题的解决不仅修复了现有的启动循环问题，更重要的是增强了OpenTitan安全启动机制的健壮性。通过引入完整性校验和优化错误处理逻辑，系统能够更好地应对意外断电等异常情况，确保设备在各种条件下都能安全可靠地启动。这对于OpenTitan作为开源安全芯片项目来说至关重要，特别是在关键基础设施和高安全性应用场景中。