北京
作者 | Olimpiu Pop
译者 | 明知山
谷歌安全团队验证了一条消除遗留基础设施中内存漏洞的新路径——利用 Gemini 将 C 语言代码库翻译成内存安全的 Rust 等价代码。该项目的改造对象是 giflib——一个约 3000 行代码的图像处理库，经常在无沙箱隔离的情况下解码不受信任的用户输入。团队用 Rust 编写了一个 ABI 兼容、可直接替换的库，停用了进程隔离沙箱、保持原有延迟不变，并在漏洞 CVE-2026-26740 被公开编目之前修复了一个尚未打补丁的堆写入零日漏洞。
内存损坏类漏洞在成熟 C/C++ 代码栈的高危安全漏洞中约占 70%。软件工程师 Bastian Kersting 和 Max Hils 没有选择耗时数年的手动移植，也没有完全依赖运行时边界检查，而是设计了一个围绕自主反馈循环的三阶段自动化迁移流程。
首先，团队使用一次性提示词让 Gemini 将 C 语言库的完整逻辑移植到 Rust。由于该库需要透明地替换现有共享对象而不破坏下游调用方，工程师保留了原有的导出符号和结构体定义。在最初几轮实现中，外部函数接口（FFI）建模引入了不安全的裸指针语义，需要人工检查并细化指针所有权和生命周期不变量。最后，自动化差异测试引擎检测到行为差异，并将失败的执行轨迹反馈给模型迭代生成补丁。
图片来源：基于博客原文内容使用 Gemini 生成。
为了避免跨 C 语言边界传递指针时产生未定义行为，FFI 封装层会从裸指针重建安全的 Rust 句柄：
}将自动生成的代码部署到核心业务基础设施，必须证明它和原 C 语言实现的语义完全等价。团队搭建了一个验证流水线，对超过 3000 万个真实的 GIF 文件进行大规模回归解码测试，确保逐比特渲染结果的一致性。
与此同时，一个自动化 差异模糊测试器 连续六天对两个运行时进行并排迭代，累计执行 2 亿次迭代没有发现功能漂移。测试套件还加入了对抗性 LLM 评估提示词，用于分析两个代码仓库，寻找潜在的行为分歧。该验证流水线在 LZW 解压器中发现了一个未处理的边缘情况，并标记出一个内部遗留的越界写入漏洞——该问题由早期原始 C 源码的一个内部补丁引入。
该项目最有力的验证出现在预发布阶段。一位外部安全研究人员在上游 giflib 中发现了一个越界堆写入漏洞，后被编目为 CVE-2026-26740。在漏洞公开披露前，谷歌这套 Rust 替代版本的生产节点从底层就不受该漏洞影响，这表明架构级的语言迁移能够从根本上预先杜绝一整类漏洞。
用 Rust 替换 C 语言库时，人们常常担心强制边界检查会带来运行时开销。全球图像解码集群的生产监控数据表明，Rust 二进制程序和原版 C 语言程序运行性能持平。而且，内存安全保障直接被移入类型系统，平台工程师因此可以移除之前为隔离图像解码任务而设置的传统操作系统沙箱。去掉这层进程隔离边界后，P99 尾部延迟显著降低。
尽管性能有所提升，作者也指出：AI 代码翻译并非可以完全放手不管的灵丹妙药。每当上游发布新功能或架构改动时，将上游 C 语言依赖分叉成 Rust 库都会带来持续的维护分叉。此外，外部函数接口封装仍然需要领域专家介入，防止生命周期泄漏，保证线程安全约束不被破坏。
r/rust 和 Hacker News 上的相关讨论普遍认可这一成果，同时也在争论 AI 辅助移植的实用性与安全性：评论者称赞了谷歌严谨的差异模糊测试框架——它捕捉到了谷歌自家遗留 C 语言补丁中的一个既有的越界写入漏洞——但大家对“一次性直接翻译”方案提出很多质疑，指出人工审计细微语义退化、修复不安全的 C FFI 边界所需要的工作量往往远超代码生成本身。许多人认为，如果代码库的规模超出 giflib 这类简单、自包含的项目，采用确定性转译器（如 c2rust），再借助 AI 重构为安全、地道的 Rust 代码，会更加可靠。
谷歌已经把生成的库开源，项目名叫 giflib-rs，供那些考虑对基础工具做自动语言迁移的团队作为参考实现。
查看英文原文：
https://www.infoq.com/news/2026/09/c-rust-rewrite/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
