AI生成的Rust代码完美编译。这正是可怕之处。
内容提要
Canonical资助布里斯托大学研究，利用AI工具将旧C代码自动重写为安全Rust，并以AppArmor和snap-confine为测试对象。研究重点在于验证生成代码与原C行为一致，避免依赖unsafe，结合模糊测试和符号修复确保内存安全及功能等价，旨在解决大规模重写中的信任问题。
延伸解读
编译通过不等于行为一致
文章强调，AI生成的Rust代码即使能完美编译，也可能在行为上与原始C代码存在差异。对于AppArmor这类安全关键模块，策略解析或执行逻辑的细微偏差可能导致安全后果。因此，验证过程必须超越传统测试，采用模糊测试与形式化分析结合，才能发现隐藏的语义差异。
unsafe的取舍是核心挑战
自动翻译C代码时，过度依赖unsafe会引入原始内存安全风险，而完全避免则可能难以保持行为等价。研究的目标是在安全性与功能一致性之间取得平衡。这要求翻译工具不仅生成代码，还要通过符号修复等手段主动调整，确保生成的Rust既符合语言惯例，又保留原意。
信任是规模化重写的瓶颈
手动重写大型C代码库成本高昂，而AI生成代码已不是难题。真正阻碍自动化重写的是开发者对生成代码的信任。Canonical资助的研究正是为了建立这种信任，通过严格的验证流程证明生成的Rust在内存安全和功能上与旧代码等价，从而为大规模采用铺平道路。
Q&A
Canonical资助布里斯托大学进行什么研究？
Canonical资助布里斯托大学研究如何利用AI工具将旧C代码自动重写为安全、可维护的Rust代码，并确保重写后的代码与原C代码行为一致。
为什么AI生成的Rust代码即使编译通过也可能有问题？
因为生成的Rust代码可能编译干净，但在行为上与原C代码不同，例如对AppArmor策略的解释可能不同，导致安全后果。
布里斯托大学的研究团队如何验证生成的Rust代码与原C代码行为一致？
他们结合模糊测试和形式化程序分析来比较两种实现，发现常规测试可能遗漏的差异。当检测到不匹配时，使用符号修复来诊断并修复代码。
为什么在Rust重写中过度使用unsafe会带来风险？
因为unsafe块允许原始指针操作等不安全操作，过度使用会将C代码中的内存安全风险带入Rust代码，削弱Rust的安全优势。
为什么选择AppArmor和snap-confine作为测试对象？
因为它们是安全关键的组件，AppArmor限制应用访问，snap-confine创建沙箱环境。翻译错误可能导致安全后果，适合测试自动化重写的可靠性。
将C代码重写为Rust能消除哪些类型的安全漏洞？
可以消除use-after-free和缓冲区溢出等内存安全漏洞，但自动化翻译仍可能引入逻辑错误。
为什么手工将C代码重写为Rust不可行？
因为操作系统、库和基础设施中有数十万行C代码，手工重写需要大量工程工作，且可能引入回归问题。
