Rustls项目对无原子操作目标平台的no-std支持探讨

Rustls作为Rust生态中重要的TLS实现库，在0.23.0版本开始支持no-std/alloc环境，这对于嵌入式系统开发具有重要意义。然而，当前实现存在一个关键限制：它依赖于标准库中的Arc类型，而该类型需要底层平台支持原子操作。

问题背景

在嵌入式开发领域，特别是使用ESP32-C2、ESP32-C3和ESP32-S2等微控制器时，这些平台通常不具备硬件原子操作支持。虽然Rust社区提供了portable-atomic这样的crate来提供原子操作功能，但Rustls当前架构直接使用了alloc::sync::Arc，这在无原子操作支持的平台上无法工作。

解决方案探讨

针对这一问题，Rustls社区提出了两种主要解决方案：

1. 全局替换Arc为Rc方案：将所有Arc使用替换为crate内部的类型别名，在无原子操作平台上使用Rc替代。这种方案的代价是相关类型将失去Send和Sync特征约束，意味着Rustls实例无法跨线程共享，每个线程需要维护自己的配置实例。

2. 使用portable-atomic-util方案：通过依赖portable-atomic-util crate，使用其提供的Arc功能实现。这种方案可以保持现有的线程安全特性，但需要解决一些技术挑战。

技术挑战与实现考量

在实现过程中，开发团队遇到了几个关键挑战：

• CI测试覆盖问题：现有的no-std测试使用x86_64-unknown-none目标平台，该平台支持原子操作，难以检测无原子操作平台特有的问题。

• 特征边界条件：方案1需要根据目标平台条件性地调整特征边界(Send/Sync)，这会显著增加代码复杂度。

• 依赖兼容性问题：portable-atomic-util的Arc实现目前需要Rust nightly版本，且与aws-lc-rs和ring等加密后端存在兼容性问题。

• 错误处理问题：现有的OtherError类型包含Arc，这在无原子操作平台上需要特殊处理。

当前进展与未来方向

目前社区已提交了基于portable-atomic-util的实现方案，虽然仍有一些限制，但已能在无原子操作平台上基本工作。考虑到嵌入式开发通常使用Rust nightly版本，这一方案具有实用价值。

对于长期支持，社区需要考虑：

1. 如何在不影响主分支稳定性的情况下支持这一特性
2. 是否将其标记为不稳定特性
3. 如何完善测试基础设施以覆盖无原子操作平台
4. 如何处理与主要加密后端的兼容性问题

这一功能的实现将显著扩展Rustls在嵌入式领域的适用性，特别是对于资源受限且无硬件原子操作支持的微控制器平台。开发团队正在积极寻求平衡稳定性和功能扩展的最佳方案。