AWS s2n-tls项目中HashMap的Borsh序列化规范性问题解析

在AWS s2n-tls项目中使用的hashbrown库(版本0.15.0)被发现存在一个重要的序列化规范性问题，这个问题涉及到HashMap数据结构通过Borsh格式的序列化和反序列化过程。

问题本质

Borsh是一种二进制序列化格式，特别强调确定性输出。对于HashMap这样的数据结构，Borsh规范要求无论键值对的插入顺序如何，相同的键值对集合必须产生完全相同的二进制表示。然而在hashbrown 0.15.0版本中，HashMap的Borsh序列化实现未能满足这一要求。

技术影响

这个问题会导致两个主要的技术后果：

1. 非规范序列化：相同的HashMap内容，如果构建时键值对的插入顺序不同，会产生不同的二进制表示。这与Borsh格式的设计原则相违背。

2. 缺乏验证：在反序列化过程中，代码没有检查输入数据是否符合规范形式，可能接受非规范的序列化数据。

实际风险

在分布式系统特别是区块链等对一致性要求极高的场景中，这种问题可能造成严重后果：

• 共识分裂：不同节点可能对逻辑上相同的数据结构产生不同的哈希值
• 安全问题：可能利用非规范序列化制造不一致的系统状态
• 数据完整性问题：系统可能将逻辑上等价的HashMap视为不同对象

解决方案

该问题已在hashbrown 0.15.1版本中得到修复。修复方案包括：

1. 确保序列化时总是产生规范的二进制表示
2. 在反序列化时增加对输入规范性的检查

值得注意的是，修复此问题需要将最低支持的Rust版本(MSRV)提升至1.65.0，因为修复方案依赖该版本引入的语言特性。

最佳实践建议

对于使用类似技术的开发者，建议：

1. 及时升级到hashbrown 0.15.1或更高版本
2. 在涉及共识算法的场景中，特别注意数据结构的序列化确定性
3. 考虑在关键路径上增加序列化规范的验证逻辑
4. 定期审计依赖库中与序列化相关的实现

这个问题提醒我们，在安全敏感的项目中，即使是标准库或广泛使用的工具库中的基础功能，也可能隐藏着微妙但重要的规范性问题，需要开发者保持警惕。