谷歌用AI将giflib从C迁移至Rust

谷歌安全团队尝试用生成式 AI 解决遗留 C 语言基础设施中的内存安全问题。他们选择的对象是 giflib，一个约 3000 行代码的图像处理库，常用于在没有沙箱保护的环境中解码不可信用户输入。团队借助 Gemini 将其改写为 ABI 兼容的 Rust 实现，使新库可以直接替换原有共享对象，同时关闭进程级隔离沙箱、保持延迟不变，并在 CVE-2026-26740 公开编号前避免了一个尚未修复的堆写入零日漏洞影响。

在成熟的 C/C++ 代码体系中，内存损坏问题约占高危安全漏洞的 70%。参与该项目的工程师没有采用多年手工移植路线，也没有只依赖运行时边界检查，而是设计了一个三阶段迁移流程：先让 Gemini 根据一次性提示词生成完整 Rust 版本，再通过人工校准外部函数接口，最后用自动化差异测试把失败轨迹反馈给模型持续修补。

由于目标是透明替换既有库而不影响下游程序，Rust 版本保留了原有导出符号和结构体定义。早期生成结果在 FFI 建模时仍存在不安全的裸指针语义，工程师需要逐项检查指针所有权、生命周期等约束，防止跨语言边界出现未定义行为。相关封装层会从 C 侧传入的裸指针重建安全的 Rust 句柄，例如在关闭 GIF 文件的接口中检查空指针、接管对象并在错误时写回错误码。

为了证明自动生成代码能够进入核心生产环境，团队建立了大规模验证流水线。他们使用超过 3000 万个真实 GIF 文件进行回归解码测试，要求新旧实现的逐比特渲染结果保持一致。同时，一个差异模糊测试器连续 6 天并排运行两个版本，完成约 2 亿次迭代后没有发现功能漂移。

测试体系还加入了面向大语言模型的对抗性评估提示，用于分析两个代码库中可能存在的行为差异。验证过程中，系统发现了 LZW 解压器里的一个未处理边界情况，并标出一个内部遗留的越界写入问题，该问题源于早期对原始 C 代码的一处内部补丁。预发布阶段，外部研究人员又在上游 giflib 中发现越界堆写入漏洞，后来被编号为 CVE-2026-26740；由于生产环境已使用 Rust 替代版本，相关节点从底层不受该漏洞影响。

性能方面，生产监控显示，Rust 二进制程序与原 C 版本基本持平。由于内存安全能力被转移到类型系统中，平台工程师得以移除过去为图像解码任务配置的操作系统沙箱，减少进程隔离带来的开销，并使 P99 尾部延迟明显下降。

不过，该项目并不意味着 AI 翻译代码可以完全无人监管。团队指出，当上游 C 库继续发布新功能或进行架构调整时，维护一个 Rust 分叉会带来长期成本；FFI 封装仍需要领域专家参与，以避免生命周期泄漏、线程安全约束被破坏等问题。相关社区讨论也认为，对于规模大于 giflib 这类自包含项目的代码库，先用确定性转译器如 c2rust 迁移，再借助 AI 重构成更安全、符合 Rust 风格的代码，可能更稳妥。谷歌已将生成库以 giflib-rs 名称开源，供其他团队评估自动化语言迁移方案。