OP-TEE中fTPM TA读取RPMB持久化值时崩溃问题分析

问题现象

在使用u-boot、OP-TEE和fTPM在rk3399平台上搭建measured boot环境时，遇到了一个严重的技术问题。当Linux内核加载tpm_ftpm_tee模块时，fTPM会立即崩溃。从日志中可以观察到，系统在尝试读取RPMB中的持久化值时出现了MAC校验失败的情况。

技术背景

measured boot是一种安全启动机制，它通过u-boot测量Linux内核、initramfs和dtb等关键组件，并将这些测量值存储在fTPM中。fTPM的持久存储由RPMB（Replay Protected Memory Block）提供支持。RPMB是一种具有重放保护特性的安全存储区域，常用于存储敏感数据。

问题排查过程

1. 初步分析：从错误日志中可以看到"MAC mismatched"提示，这通常表明RPMB密钥验证失败。但考虑到使用的是OP-TEE内置的测试密钥，且u-boot和Linux都不应干扰该密钥，这种可能性较低。

2. FAT版本考虑：怀疑可能是FAT版本不兼容导致的问题，尝试使用CFG_RPMB_RESET_FAT清除RPMB的FAT，但未能解决问题。

3. 功能验证：通过u-boot的tpm2 self_test full命令确认fTPM和RPMB基本功能正常，在自测过程中可以观察到OP-TEE成功访问RPMB的日志。

根本原因

经过深入分析，发现问题根源在于tee-supplicant的配置。系统使用了Debian打包的tee-supplicant，该版本默认启用了RPMB_EMU（RPMB模拟）选项。当tee-supplicant运行在RPMB模拟模式下时，它会使用模拟的RPMB存储而非真实的硬件RPMB，这导致与fTPM TA期望访问真实RPMB的行为产生冲突。

解决方案

解决该问题的正确方法是重新编译tee-supplicant，确保RPMB_EMU配置选项被禁用（设置为n）。这样可以保证tee-supplicant使用真实的硬件RPMB而非模拟环境。

改进建议

从用户体验角度考虑，建议在tee-supplicant中添加明确的日志输出，指示当前是使用模拟RPMB还是真实硬件RPMB。这将有助于开发者在遇到类似问题时更快定位原因。

总结

这个案例展示了在构建安全启动链时，各组件配置一致性的重要性。特别是在涉及安全存储如RPMB时，必须确保所有相关组件对存储介质的认知一致。开发者在使用预编译的软件包时，需要特别注意其默认配置可能与自定义的安全方案不兼容。