谷歌用 Gemini 把 3000 行 C 库改写成 Rust：2 亿次差分测试零漂移，还提前挡下一个零日漏洞

内存安全漏洞一直是成熟 C/C++ 代码库最头疼的顽疾。在公认的高危安全漏洞里，内存损坏类问题占了约七成。手工把老代码迁移到内存安全语言，动辄要花数年。谷歌安全团队验证了一条新路径：让 AI 来翻译。

一分钟速览

• 谷歌安全团队用 Gemini 把约 3000 行的 C 图像库 giflib 翻译成 ABI 兼容的 Rust 实现；
• 新库可直接替换原共享对象，停用了进程隔离沙箱，延迟保持不变；
• 团队还提前修复了一个堆写入零日漏洞，该漏洞后来被编目为 CVE-2026-26740；
• 验证阶段跑过 3000 万个真实 GIF 文件，差分模糊测试累计 2 亿次迭代未发现功能漂移；
• 生成的 Rust 库已开源，项目名为 giflib-rs。

深度分析

为什么盯上 giflib

giflib 是一个约 3000 行代码的图像处理库，经常在没有沙箱隔离的情况下解码不受信任的用户输入，是典型的「高危又难换」的老组件。工程师 Bastian Kersting 和 Max Hils 没有选择耗时数年的手工移植，也没有完全依赖运行时边界检查，而是设计了一个围绕自主反馈循环的三阶段迁移流程。

三阶段流程：翻译、修边界、验证

第一步，用一次性提示词让 Gemini 把 C 库的完整逻辑移植到 Rust。为了让新库能透明替换原有共享对象而不破坏下游调用方，团队保留了原有的导出符号和结构体定义。

第二步，处理最容易出事的边界。最初几轮实现里，外部函数接口（FFI）建模引入了不安全的裸指针语义，需要人工检查并细化指针所有权与生命周期不变量。团队为此写了严谨的封装层，从裸指针重建安全的 Rust 句柄，避免跨语言边界传指针时产生未定义行为。

第三步，用自动化差分测试引擎检测两个运行时的行为差异，并把失败的执行轨迹反馈给模型，迭代生成补丁。

怎么证明「完全等价」

要把自动生成的代码部署到核心基础设施，必须证明它与原 C 实现语义完全一致。团队搭了一条验证流水线：对超过 3000 万个真实 GIF 文件做大规摸回归解码，确保逐比特渲染结果一致；同时用自动化差分模糊测试器连续 6 天对两个运行时并排迭代，累计执行 2 亿次迭代，没有发现功能漂移。测试套件还加入了对抗性 LLM 评估提示词，用来寻找两个代码库之间潜在的行为分歧——这套流程在 LZW 解压器里发现了一个未处理的边缘情况，并标记出一个由早期 C 源码内部补丁引入的越界写入漏洞。

最有说服力的验证

项目预发布阶段，一位外部安全研究人员在上游 giflib 中发现了一个越界堆写入漏洞（CVE-2026-26740）。在漏洞公开披露之前，谷歌这套 Rust 替代版本的生产节点从底层就不受该漏洞影响——这说明架构级的语言迁移能从根本上预先杜绝一整类漏洞。

数据支撑

• giflib 约 3000 行 C 代码；内存损坏类漏洞约占高危漏洞的 70%；
• 3000 万个真实 GIF 回归测试；差分模糊测试 2 亿次迭代、连续 6 天零功能漂移；
• 移除沙箱后 P99 尾部延迟显著降低，Rust 版本与原 C 版本运行性能持平。

产品链接

• giflib-rs 开源项目（谷歌）：https://github.com/google/giflib-rs
• Rust 语言官网：https://www.rust-lang.org

趋势洞察

谷歌同时提醒：AI 代码翻译不是可以完全放手不管的灵丹妙药。每次上游发布新功能或架构改动，分叉出来的 Rust 库都会带来持续的维护负担，FFI 封装仍需要领域专家介入，防止生命周期泄漏和线程安全问题。社区的主流意见也偏谨慎：对于 giflib 这类简单、自包含的项目，AI 一次性翻译可行；但规模更大之后，更可靠的路线或许是先用确定性转译器（如 c2rust）打底，再用 AI 重构为安全、地道的 Rust。这也许正是 AI 参与遗留系统改造的正确姿势——不是取代工程师，而是把最难啃的那部分脏活自动化。