OpenSSL项目中FIPS模式下RAND_seed调用死锁问题分析与修复

在OpenSSL项目的开发过程中，我们发现了一个在FIPS模式下调用RAND_seed函数时出现的死锁问题。这个问题涉及到多线程环境下的锁竞争，以及OpenSSL内部随机数生成器的初始化流程。

问题背景

当程序显式加载'legacy'、'default'和'fips'三个provider后调用RAND_seed()函数时，会出现程序挂起的情况。通过分析堆栈跟踪，我们发现死锁发生在CRYPTO_THREAD_read_lock调用处。

死锁原因分析

问题的根本原因在于OpenSSL内部锁的使用方式：

1. 在rand_get0_primary()函数中，首先获取了dgbl->lock锁
2. 随后在ossl_rand_get0_seed_noncreating()函数中，又尝试获取同一个锁
3. 由于OpenSSL使用的不是递归锁，导致线程在尝试重复获取同一个锁时发生死锁

特别值得注意的是，这个问题仅在加载FIPS provider时出现。当只加载'legacy'和'default' provider时，EVP_RAND_fetch()会返回有效值，不会触发这个死锁路径。

技术细节

在OpenSSL 3.5.0版本中，EVP_RAND_fetch()的参数发生了变化：

• 3.3.2版本：使用'SEED-SRC'和'-fips'作为参数
• 3.5.0版本：使用'SEED-SRC'和空字符串作为参数

这种变化导致了不同的执行路径，最终触发了锁竞争问题。

解决方案

开发团队提出了一个修复方案，主要修改了rand_get0_primary()函数的实现逻辑：

1. 优化了锁的获取和释放顺序，避免嵌套锁
2. 重新组织了seed和primary DRBG的初始化流程
3. 增加了错误处理和资源释放逻辑

关键改进点包括：

• 提前获取seed值并暂存
• 在持有锁之前完成大部分初始化工作
• 实现了更安全的资源管理

对开发者的建议

对于使用OpenSSL FIPS模式的开发者，建议：

1. 关注OpenSSL的版本更新，及时应用修复补丁
2. 在多线程环境下使用OpenSSL时，特别注意锁的使用
3. 对于关键的安全操作，考虑添加适当的错误处理和超时机制

总结

这个案例展示了在复杂的安全库中，即使是看似简单的函数调用也可能因为多线程和模块交互而产生意料之外的问题。OpenSSL团队通过仔细分析锁的使用情况和重构初始化流程，有效地解决了这个死锁问题，为开发者提供了更稳定的FIPS模式支持。

对于安全敏感的应用，理解底层库的行为模式至关重要。这个问题的解决不仅修复了一个具体的bug，也为类似的多线程安全问题提供了参考解决方案。