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

背景介绍

在PolarSSL（现Mbed TLS）3.6.0版本中，当启用ECDSA模块（MBEDTLS_ECDSA_C）但禁用PSA加密模块（MBEDTLS_PSA_CRYPTO_C）时，psa_util.c文件中的部分代码会被错误地包含进构建过程。这导致了一个0长度数组的声明，进而引发编译错误（除非使用某些不严格的编译器）。

问题根源

问题的核心在于MBEDTLS_PSA_UTIL_HAVE_ECDSA宏的定义逻辑。在include/mbedtls/config_adjust_legacy_crypto.h文件中，该宏的定义条件为：

#if defined(MBEDTLS_ECDSA_C) || (defined(MBEDTLS_PSA_CRYPTO_C) && \
    (defined(PSA_WANT_ALG_ECDSA) || defined(PSA_WANT_ALG_DETERMINISTIC_ECDSA)))
#define MBEDTLS_PSA_UTIL_HAVE_ECDSA
#endif

这种定义方式导致即使在没有启用PSA加密模块的情况下，只要启用了ECDSA模块，PSA工具函数就会被包含进构建过程。

技术影响

在非PSA配置下，这些函数存在以下问题：

1. 声明在psa_util.h头文件中，对非PSA用户来说不易发现
2. 实际无法正常工作（由于0长度数组问题）
3. 缺乏针对非PSA配置的测试覆盖

解决方案讨论

开发团队考虑了两种解决方案：

方案一：完全移除非PSA配置下的支持

这是最终选择的方案，主要基于以下考虑：

1. 这些函数原本就是为PSA用户设计的
2. 在非PSA配置下从未真正工作过
3. 符合项目推动用户迁移到PSA API的战略方向
4. 避免在LTS版本中引入新功能

方案二：完善非PSA配置下的支持

这个方案曾被考虑，但最终被否决，原因包括：

1. 需要额外工作来确保正确性和测试覆盖
2. 与项目发展方向不符（鼓励使用PSA而非遗留API）
3. 已有用户可能已经自行解决了类似需求

实现细节

最终实现将修改MBEDTLS_PSA_UTIL_HAVE_ECDSA宏的定义逻辑，确保：

1. 只有在启用MBEDTLS_PSA_CRYPTO_CLIENT时才定义该宏
2. 非PSA配置下完全排除相关代码
3. 保持现有PSA配置下的功能不变

经验教训

这个案例提醒我们：

1. 宏定义的条件逻辑需要仔细考虑所有可能的配置组合
2. 新功能的测试覆盖需要包含所有预期支持的配置
3. 项目战略方向应该体现在技术决策中
4. API的可用性和可发现性需要统一考虑

结论

通过这个问题的解决，PolarSSL项目确保了代码在不同配置下的正确性，同时贯彻了推动用户使用现代PSA API的战略方向。这也为类似的项目提供了有价值的参考：在维护向后兼容性的同时，如何平衡功能完整性和项目发展方向。