Canonical is funding research into automated C-to-Rust translation in partnership with the University of Bristol, with work set to begin later in 2026. AppArmor and snap-confine will serve as real-world case studies.

Before anyone gets ahead of the announcement: AppArmor is not being rewritten in Rust. Neither is snap-confine. Canonical has been explicit that these codebases are being used to test the technology, and there is no plan to replace the current implementations with whatever the research produces.

What the project is actually trying to build

The goal is a platform capable of translating large repositories, sometimes hundreds of thousands of lines of C, into Rust that is safe, reliable, and maintainable.

That last word is doing a lot of work. Mechanical C-to-Rust translation is a solved problem in the narrow sense: tools like c2rust have existed for years and will happily convert C into Rust that compiles. The output is unsafe Rust that reads like transliterated C, wrapped in unsafe blocks and raw pointers, and it delivers essentially none of the safety guarantees that motivate the exercise. You end up with the same memory-safety bugs in a language whose main selling point is not having them.

The hard problem is producing idiomatic, genuinely safe Rust, which requires understanding what the C code means rather than what it does line by line.

The proposed approach

Canonical’s proposed system uses language models to generate the Rust, then runs the result through a verification process designed to catch and repair behavioral differences.

The verification half is the part that makes this a research project rather than a scripting exercise. An LLM will produce plausible Rust from C input reliably. Whether that Rust does the same thing as the original, in all the edge cases that a security-critical codebase depends on, is a separate question that the model has no way to answer about itself.

This is why AppArmor and snap-confine are useful case studies specifically. Both are security enforcement code. A translation that is 99% behaviorally identical is not a success when the remaining 1% is where a confinement boundary lives.

Our AppArmor explainer covers what that codebase is responsible for, and SELinux explained covers the other major Linux mandatory access control implementation for comparison.

Why now

The memory-safety argument has been won at the level of policy. Government agencies have published guidance pushing memory-safe languages, the Linux kernel accepts Rust, and new systems software increasingly starts in Rust by default.

The unresolved problem is the existing code. There are decades of C in production doing essential work, written by people who are often no longer available to explain it, and rewriting it by hand is expensive to the point of being theoretical for most of it.

Automated translation is the obvious lever. Whether it can be made to work at the required fidelity is exactly what nobody knows, which is a reasonable definition of a research question worth funding.

What to expect

Not much, soon. Work starts later in 2026, and this is a university research partnership rather than a product roadmap. The realistic outcome in the near term is papers and prototypes.

The reason it is worth noting anyway is that Canonical is putting money behind the “translate the existing code” approach rather than the “rewrite it eventually” approach. If the verification piece works even partially, it changes the economics of memory safety for a very large amount of software.

If it does not, that is also useful to know, and better established through a funded study than through a series of well-intentioned rewrites that quietly stall.