Mbed TLS项目中PSA工具函数在非PSA构建下的兼容性问题分析

问题背景

在Mbed TLS 3.6.0版本中，当用户启用了ECDSA功能（MBEDTLS_ECDSA_C）但禁用了PSA加密功能（MBEDTLS_PSA_CRYPTO_C）时，构建过程中会出现一个关键问题。系统会错误地包含psa_util.c文件中的部分代码，导致声明了一个大小为0的数组，从而引发编译错误（除非使用某些不太严格的编译器）。

技术细节分析

问题的根源在于include/mbedtls/config_adjust_legacy_crypto.h文件中对MBEDTLS_PSA_UTIL_HAVE_ECDSA宏的定义。当前定义允许在仅启用ECDSA而不启用PSA加密的情况下激活该宏，这显然是不合理的。

从技术架构角度看，MBEDTLS_PSA_UTIL_xxx系列宏应该只在启用MBEDTLS_PSA_CRYPTO_C（或可能是MBEDTLS_PSA_CRYPTO_CLIENT）时才被定义和使用。这些宏原本设计用于支持PSA（Platform Security Architecture）相关的功能，在没有PSA支持的环境下不应该被激活。

影响范围

这个问题主要影响以下配置场景：

1. 明确禁用了PSA加密功能的构建
2. 仅使用传统加密API而不涉及PSA的用户
3. 使用严格编译器的开发环境

值得注意的是，这个问题本应被CI测试（特别是component_test_no_psa_crypto_full_cmake_asan测试和一些参考配置）捕获，但实际上却未被发现，这表明测试覆盖存在不足。

解决方案讨论

开发团队经过深入讨论后，提出了几种可能的解决方案：

1. 完全移除方案：在非PSA配置下完全排除psa_util.c中的代码。这种方案最直接，但可能影响那些希望使用ECDSA签名转换功能但不想启用完整PSA加密功能的用户。

2. 条件编译方案：通过更精确的条件编译控制，确保在非PSA配置下使用适当的缓冲区大小定义（如使用MBEDTLS_ECP_MAX_BYTES而非PSA相关宏）。

3. 功能保留方案：保持函数在非PSA配置下的可用性，但确保它们能正常工作。这需要额外的开发和测试工作。

经过权衡，团队最终倾向于第一种方案，主要基于以下考虑：

• 这些函数声明在psa_util.h中，对非PSA用户来说本就难以发现
• 鼓励用户迁移到PSA API是项目的战略方向
• 在LTS版本中添加新功能（即使只是修复功能）需要谨慎

经验教训

这个案例给我们带来几个重要的启示：

1. 宏定义边界：在定义功能开关宏时，必须仔细考虑其适用边界条件
2. 测试覆盖：CI测试需要覆盖所有关键配置组合，特别是功能互斥的情况
3. 架构设计：功能模块的划分应该更清晰地反映其依赖关系

总结

Mbed TLS项目中PSA工具函数在非PSA构建下的兼容性问题展示了加密库开发中的典型挑战。通过这次问题的分析和解决，项目团队不仅修复了一个具体的技术问题，还进一步明确了功能边界和架构设计原则。这对于保证加密库的稳定性和可靠性具有重要意义，也为其他类似项目的开发提供了有价值的参考。