AI-written Rust gets a verification test on AppArmor

Canonical is funding researchers at the University of Bristol to test whether language models can translate the C behind AppArmor and snap-confine into Rust that behaves identically to the original. According to The New Stack, the project pairs model-generated code with a verification stage built to detect and repair behavioral differences.

At a glance

• Fuzzing and formal program analysis compare the generated Rust against the original C, while symbolic repair diagnoses the exact failure and fixes the generated code when the two implementations diverge.
• A translator can carry awkward C constructs across by leaning on Rust's unsafe blocks, which permit raw pointer manipulation and reintroduce the memory-safety risks the rewrite was supposed to remove.
• Canonical has not committed to rewriting either component in Rust, and the project's open question is whether the generate-then-verify approach holds up across repositories containing hundreds of thousands of lines of C.

The bottleneck in this kind of migration is no longer producing Rust at volume, it is convincing the people who maintain security-critical code that the output is equivalent. Canonical's choice of two confinement components reads as a deliberately unforgiving test: a mistranslated policy parser fails silently rather than loudly. What the project is really measuring is the evidence threshold maintainers need, not the translator's throughput.

A Rust port of AppArmor could compile cleanly and still read a policy wrong

AppArmor is a Linux security module that restricts what applications can access according to defined policies. Its userspace tooling, written in a mix of C, Python and C++, has to parse, compile and load those policies correctly. A Rust port that interprets a policy differently from the existing implementation could compile without error and still be wrong.

Snap-confine poses a related problem because it sets up the execution environment and confinement used by snaps. Rewriting its C in Rust can remove entire classes of vulnerabilities, including use-after-free bugs and buffer overflows, but an automated translator can still introduce a logic error the compiler will never flag.

Operating systems, libraries and infrastructure built over decades remain written in C, and much of that code is still actively maintained and deployed. Rewriting it by hand would take an enormous amount of engineering work and could introduce regressions of its own.

Fuzzing and formal analysis carry the work the compiler cannot

Generated Rust can compile cleanly and still behave differently from the original C. The proposed system generates the code with language models and then pushes it through a verification stage built to catch and repair those differences, combining fuzzing with formal program analysis to compare the two implementations and surface divergences that conventional tests may miss.

When the system detects a mismatch between the two implementations, symbolic repair diagnoses the exact failure and fixes the generated code directly. Canonical treats that feedback as central to solving the overuse of unsafe blocks, which permit operations safe Rust forbids, including some forms of raw pointer manipulation.

Leaning on unsafe would carry the original C bugs into the Rust

Getting the full benefit of Rust usually requires more than translating C syntax line by line. Writing idiomatic Rust can force changes to data structures and lifetimes across several functions or entire modules, and a translator that stays close to the original C by leaning on unsafe risks carrying the same bugs across.

The target Canonical describes is Rust that is safe enough to deliver the language's benefits and close enough in behavior to the original C for maintainers to trust it. That is why it is funding the Bristol team to test whether the approach scales to entire repositories containing hundreds of thousands of lines of C.

No AppArmor rewrite is scheduled

Canonical is not rushing to rewrite either AppArmor or snap-confine in Rust, and no timeline for a production port has been given. The stated goal of the Bristol work is narrower: to establish what evidence maintainers would need before trusting an automated translation of production code, and whether fuzzing, formal analysis and symbolic repair can supply it at repository scale.