s2n-tls项目内存泄漏问题分析与修复

问题背景

在aws/s2n-tls项目的1.5.10版本中，用户报告了一个与libcurl结合使用时出现的内存泄漏问题。这个问题在1.5.9版本中并不存在，但在升级到1.5.10版本后开始出现。该问题特别影响那些使用Amazon Linux 2默认OpenSSL版本(1.0.0/1.0.1e-fips)的环境。

问题现象

当s2n-tls与libcurl同时初始化时，如果按照特定顺序调用初始化函数，会导致内存泄漏。具体表现为：

1. 先调用s2n_init()
2. 然后调用curl_global_init()
3. 接着调用curl_global_cleanup()
4. 最后调用s2n_cleanup()和s2n_cleanup_final()

在这种情况下，内存检测工具(如ASAN)会报告一个216字节的内存泄漏，指向s2n_rand_init函数中创建的ENGINE对象。

根本原因分析

经过深入调查，发现问题源于PR#4878引入的改动。这个PR修改了s2n-tls中随机数引擎初始化的条件判断逻辑：

1. 旧版本使用简单的!defined(OPENSSL_FIPS)条件判断
2. 新版本改为同时检查OPENSSL_FIPS和FIPS_mode()，确保只有当libcrypto实际启用了FIPS模式时才不使用自定义随机数引擎

在OpenSSL 1.0.x版本中，特别是Amazon Linux 2默认安装的1.0.0/1.0.1e-fips版本，虽然这些库标称支持FIPS，但实际上已经不再获得FIPS认证。因此FIPS_mode()返回false，导致s2n-tls错误地启用了自定义随机数引擎。

当libcurl随后初始化时，它会替换或清除现有的随机数引擎，导致s2n-tls创建的ENGINE对象无法被正确释放，从而产生内存泄漏。

解决方案

开发团队经过多次讨论和测试，最终确定了以下修复方案：

1. 对于OpenSSL 1.0.x版本，特别是那些标称支持FIPS但实际上已过期的版本，保持与旧版本相同的行为
2. 仅在确认libcrypto实际支持并启用了FIPS模式时，才禁用s2n-tls的自定义随机数引擎
3. 增加对OpenSSL版本的特殊处理，避免在老版本上启用可能导致问题的功能

影响范围

该问题主要影响以下环境：

• 使用OpenSSL 1.0.x版本的系统
• 特别是Amazon Linux 2默认安装的环境
• 同时使用s2n-tls和libcurl的应用程序

对于使用较新OpenSSL版本(1.1.x或更高)的环境，该问题不会出现。

最佳实践建议

对于开发者而言，可以采取以下措施避免类似问题：

1. 尽量保持依赖库的更新，使用较新的OpenSSL版本
2. 如果必须使用旧版本，考虑调整初始化顺序：
   • 先初始化libcurl
   • 然后初始化s2n-tls
   • 最后按相反顺序清理
3. 在项目中集成内存检测工具，如ASAN，及早发现潜在的内存问题

总结

这个案例展示了开源库之间复杂的交互可能导致的微妙问题。通过深入分析版本差异和初始化顺序的影响，开发团队成功定位并修复了内存泄漏问题。这也提醒我们在升级依赖库时需要全面测试，特别是当改动涉及底层加密功能时。