Canonical is Funding a PhD to Automate C to Rust Translation for Ubuntu

Canonical has committed funding to a three-year PhD project focused on building a system that can automatically translate large C codebases into Rust.

And they are not alone; UK Research and Innovation is matching their funding for the project, which is set to run through the University of Bristol’s Programming Languages Research Group.

The PhD is aiming to build an all-encompassing platform that can take a C repository running into hundreds of thousands of lines and translate it into Rust that’s “safe, behaviourally correct and maintainable Rust.”

The work will be carried out by a student, Alex Wood, who will be supported by Professor Meng Wang leading the work, with Dr. Cristina David and Canonical’s Jon Seager serving as co-supervisors.

How would this work?

Getting from C to Rust automatically means solving a few separate problems, and the system tackles them in sequence. First, it has to break a massive codebase into pieces small enough to work with without losing track of how those pieces depend on each other elsewhere in the code.

Only then does the actual translation happen, handled by language models that have already been trained on real C-to-Rust conversions, with the goal of writing code that looks like something a Rust developer chose to write rather than C dressed up in Rust syntax.

That’s the easier half. The harder task is proving the translated code actually behaves like the original, which is where fuzzing and formal equivalence checks come in.

When something doesn’t line up, a separate repair step tries to track down exactly where the translation went wrong and patch it using symbolic program-repair techniques instead of starting the whole chunk over.

Jon points out that the language model handles only one part of the job. Whatever it generates still has to clear validation before anyone can trust that it kept the original behavior intact.

The targeted test case

Both AppArmor and snap-confine already run in production on real Ubuntu systems, handling access control and sandboxing that most users never see but rely on constantly.

That’s why they were picked, not because they are simple, but because Canonical wants industrial-grade test cases that offer a much better look at how the approach holds up under real production conditions.

Testing a live component carries with it everything that’s built up around it through years of real use, which makes it a far harder thing to translate without breaking something, and that’s the point.

Jon also flagged an important caveat, noting that nothing generated by this project is going into either tool anytime soon. The point, he said, is that Canonical has “a vested interest in the software and are keen to see the results,” not that a rewrite is coming.

Why should you care?

If the approach survives this test, Canonical will have a real answer to whether automated translation can be trusted with code that protects the system, not just the code that was easy to test on.

As a result, Ubuntu users, from regular desktop installs to enterprise deployments, could eventually see security-critical components with fewer bugs without Canonical having to gamble on a time-consuming manual rewrite of sensitive code.