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