GoogleRustAISecurity

谷歌借助 AI 与差分模糊测试将 C 语言依赖库改写为 Rust

Olimpiu Pop··原文链接
收录于 2026/10/14 19:47:01

谷歌安全团队验证了一条消除遗留基础设施中内存漏洞的新路径——利用 Gemini 将 C 语言代码库翻译成内存安全的 Rust 等价代码。该项目的改造对象是 giflib——一个约 3000 行代码的图像处理库,经常在无沙箱隔离的情况下解码不受信任的用户输入。团队用 Rust 编写了一个 ABI 兼容、可直接替换的库,停用了进程隔离沙箱、保持原有延迟不变,并在漏洞 CVE-2026-26740 被公开编目之前修复了一个尚未打补丁的堆写入零日漏洞。

内存损坏类漏洞在成熟 C/C++ 代码栈的高危安全漏洞中约占 70%。软件工程师 Bastian Kersting 和 Max Hils 没有选择耗时数年的手动移植,也没有完全依赖运行时边界检查,而是设计了一个围绕自主反馈循环的 三阶段自动化迁移流程:

图1:谷歌 AI 辅助 C→Rust 三阶段迁移流程示意图(Gemini 翻译 → FFI 安全建模 → 差分模糊测试反馈循环)

第一阶段:AI 翻译

团队使用一次性提示词让 Gemini 将 C 语言库的完整逻辑移植到 Rust。由于该库需要透明地替换现有共享对象而不破坏下游调用方,工程师保留了原有的导出符号和结构体定义。在最初几轮实现中,外部函数接口(FFI)建模引入了不安全的裸指针语义,需要人工检查并细化指针所有权和生命周期不变量。

第二阶段:FFI 安全封装

为避免跨 C 语言边界传递指针时产生未定义行为,FFI 封装层会从裸指针重建安全的 Rust 句柄。以下代码展示了 DGifCloseFile 的封装逻辑——通过 Box::from_raw 将裸指针转换为拥有所有权的 Rust 句柄,在安全作用域内完成资源释放:

#[no_mangle]
pub unsafe extern "C" fn DGifCloseFile(
    gif_file: *mut GifFileType,
    error_code: *mut c_int,
) -> c_int {
    if gif_file.is_null() {
        return GIF_ERROR;
    }
    let mut handle = Box::from_raw(gif_file as *mut GifFilePrivate);
    match handle.close() {
        Ok(_) => GIF_OK,
        Err(e) => {
            if !error_code.is_null() {
                *error_code = e.to_raw();
            }
            GIF_ERROR
        }
    }
}

第三阶段:差分模糊测试与大规模验证

将自动生成的代码部署到核心业务基础设施,必须证明它和原 C 语言实现的语义完全等价。团队搭建了两套验证机制:

  • 大规模回归解码测试:对超过 3000 万个真实 GIF 文件进行逐比特渲染结果一致性验证。
  • 差分模糊测试:连续六天对两个运行时(C 原版与 Rust 版)进行并排迭代,累计执行 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 代码,会更加可靠。

谷歌已经把生成的库开源,项目名叫 giflib-rs,供考虑对基础工具做自动语言迁移的团队作为参考实现。

英文原文:https://www.infoq.com/news/2026/09/c-rust-rewrite/

评分:
暂无(0 人评分)