北京
一个只有约3000行代码的图像处理库，被谷歌安全团队盯上了。这个库叫giflib，专门解码用户上传的GIF图片——也就是说，它处理的是完全不可信的外部输入，而且长期没有沙箱隔离。团队用Gemini把它的C代码整体翻译成了内存安全的Rust版本，做成ABI兼容的替代库，直接替换掉原来的共享对象。
结果不只是"换了个语言"这么简单。替换上线后，团队拆掉了原本用来隔离图像解码任务的进程沙箱，延迟没有变差，反而在p99尾延迟上有明显下降。更关键的是，一个尚未被公开收录的堆写入零日漏洞，在生产节点上被这套Rust实现天然免疫——这个漏洞后来才被编为CVE-2026-26740。
为什么值得动这个刀
在成熟的C和C++技术栈里，内存破坏类漏洞大约占严重安全漏洞的70%。传统解法无非两条路：要么花好几年人工重写，要么依赖运行时的边界检查兜底。谷歌的两位工程师Bastian Kersting和Max Hils选了第三条路——一套围绕自主反馈循环设计的三阶段自动化迁移流程。
第一步，用单次提示让Gemini把整个C库的逻辑移植成Rust。因为新库要透明替换掉原有的共享对象、不能破坏下游调用方，团队保留了原来导出的符号和结构体定义。这一步并不顺利：在建模外部函数接口（FFI）时，早期迭代引入了不健全的裸指针语义，必须由人类专家介入，检查并修正指针所有权和生命周期约束。
第二步，自动化差分测试引擎负责找出行为差异，把失败轨迹回喂给模型，让它迭代生成补丁。第三步，反复循环，直到行为收敛。
为了在跨C边界传递指针时不触发未定义行为，FFI包装层会从裸指针重建安全的Rust句柄。比如关闭文件这个函数，会先判断指针是否为空，再用Box::from_raw把裸指针还原成内部结构体，最后调用关闭逻辑并根据结果返回成功或错误码。
验证比翻译本身更狠
要把自动生成的代码部署到关键基础设施上，必须证明它和历史上的C实现语义等价。团队搭了一条验证流水线：
- 对超过个真实GIF资源做大规模回归解码，确保逐比特的渲染一致性；
- 自动化差分模糊测试让两套运行时并排跑，连续6天、累计2亿次迭代，没有观察到功能漂移；
- 测试套件里还加入了对抗性的LLM评估提示，让模型同时分析两个代码仓库，定位潜在的行为分叉。
这条流水线抓出了两个问题：一个是LZW解压器里未被处理的边界情况，另一个是原始C源码中由早前内部补丁引入的越界写入。后者尤其讽刺——问题出在谷歌自己的历史补丁里，被差分模糊测试逮了个正着。
最有力的验证发生在灰度阶段。一位外部安全研究员在上游giflib里发现了越界堆写入，也就是后来的CVE-2026-26740。此时运行谷歌编译版Rust替换库的生产节点，在漏洞公开披露之前就已经结构性地免疫了这个问题。这说明语言层面的架构迁移，本身就能提前消掉一整类漏洞。
把C库换成Rust，通常会被担心强制边界检查带来的运行时开销。但全球图像解码集群的生产遥测显示，Rust二进制与原始C二进制处于运行时持平状态。而且因为内存安全保证被直接搬进了类型系统，平台工程师得以拆除那些原本用来隔离图像解码任务的遗留操作系统沙箱。去掉这层进程隔离边界之后，p99尾延迟出现了显著下降。
AI翻译不是甩手掌柜
作者们强调，AI翻译并非一劳永逸的万能药。把上游C依赖fork成Rust仓库，意味着只要上游发布新功能或架构改动，就会产生持续的维护分叉。此外，FFI包装层仍然需要人类领域专家来防止生命周期泄漏、保证线程安全约束不被破坏。
r/rust和Hacker News上的讨论普遍认可这项成果，同时也在争论AI辅助移植的实用性和安全性。评论者称赞谷歌严格的差分模糊测试框架——正是它抓出了谷歌自己遗留C补丁里的越界写入——但对"单次提示翻译"的做法提出了大量质疑。核心观点是：审计细微语义回归、修复不健全的C FFI边界所需的人力，往往远超代码生成本身。不少人认为，随着库的规模超出giflib这种简单自包含的目标，更可靠的路子可能是先用确定性转译器（比如c2rust），再用AI驱动重构，把它变成安全、地道的Rust。
谷歌已经把成果作为开源项目发布，名字叫giflib-rs，定位是给那些正在评估自动化语言迁移方案的团队提供一份参考实现。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
