Canonical tackles the real barrier to AI-powered C-to-Rust translation: proving trustworthiness

Getting AI to produce working Rust code is becoming straightforward. Knowing whether that code is actually safe and behaves like the original C it replaces? That's still the hard part. Canonical and University of Bristol researchers are working to bridge that gap, starting with two of Linux's most security-sensitive components: AppArmor and snap-confine.

Why behavioral equivalence matters#

The real challenge with automating C-to-Rust translation isn't code generation anymore—it's validation. Generated Rust can compile without errors while silently diverging from the original behavior. A translation tool must do more than produce syntactically correct code; it must prove the new implementation performs identically to decades-old C code that's still running in production.

Canonical's proposed approach combines language models for code generation with fuzzing and formal program analysis. When the system discovers mismatches between the C and Rust versions, it uses symbolic repair to diagnose and fix the discrepancies automatically. This feedback loop is essential for controlling the use of unsafe blocks—Rust constructs that bypass memory safety guarantees and could undermine the whole point of rewriting in Rust.

High stakes with security tools#

AppArmor and snap-confine serve as rigorous test cases because errors have immediate security implications. AppArmor enforces access policies across the system, while snap-confine manages sandboxed runtime environments. Even a perfectly compiling Rust translation that misinterprets a policy or misconfigures a confinement boundary could introduce vulnerabilities without triggering any existing test.

Rust can eliminate entire classes of bugs—use-after-free conditions, buffer overflows—but an automated translator can still introduce logic errors that conventional testing won't catch. The Bristol team must demonstrate that the translated behavior remains functionally identical to the original C across real-world scenarios.

The unsafe block trap#

Idiomatic Rust often requires rearchitecting data structures and lifetime patterns across multiple functions. An automated translator could sidestep this work by leaning heavily on unsafe blocks, staying mechanically close to the original C but preserving its vulnerabilities in the process. The goal is Rust that's both demonstrably safe and trustworthy enough for maintainers to accept—not just syntactically equivalent.