Investing in automated C to Rust translation - Project Discussion - Ubuntu Community Hub

Investing in automated C to Rust translation

Project Discussion

blog

jnsgruk

August 19, 2026, 1:17pm

cover1500×843 316 KB

I have written before about the role that Rust will play in Ubuntu’s future. The case for Rust in 2026 is clear: it gives systems programmers more ergonomic control over performance and resource use while eliminating many classes of memory-safety defects, making it especially useful for software operating at important security boundaries.

The harder question is what to do about the enormous amount of mature C code that already exists? Rewrites have long been expensive and risky, and do not often materialise obvious improvements. Established codebases often contain years of bug fixes, compatibility decisions, operational knowledge and hard-won performance optimisations.

Our approach to modernisation in Ubuntu has been forward-looking, but pragmatic. The new technologies we’ve adopted have earned their place in Ubuntu. The uutils coreutils project and sudo-rs are both established projects with mature test suites and committed maintainers and communities. If we want more systems software to benefit from memory safety, we need better ways to reduce the cost and risk of migration.

That is the problem behind a new research partnership between Canonical and the University of Bristol in the UK.

Project Goals

Canonical is funding a 3-year PhD project, with matched support from UK Research and Innovation, to investigate increasing the rigour of automated C to Rust translations. The project will be led in Bristol by Professor Meng Wang, with Dr Cristina David and myself as co-supervisors.

The goal is to build an end-to-end platform capable of translating repositories comprising hundreds of thousands of lines of C to safe, behaviourally correct and maintainable Rust.

Traditional source-to-source translators can process substantial amounts of code, but often preserve the structure of the C too literally. The result may compile as Rust, but still rely heavily on unsafe operations, retain awkward C idioms and require significant manual work before it resembles code a Rust maintainer would choose to own.

Large language models have almost the opposite characteristics. They can produce convincing, idiomatic Rust for small and well-defined examples, but they struggle with repository-scale context. More importantly, plausible-looking output is not evidence that the translated program behaves like its source.

A neurosymbolic approach

The project will combine machine-learning techniques with conventional program analysis, testing and formal methods. The proposed architecture has four main parts.

Scheduling will divide a large repository into chunks that can be translated independently, without losing the context required to understand types, dependencies and behaviour. This is more involved than splitting a project by file or function. The order and boundaries of translation affect how much the system can infer and what it can subsequently validate.

Translation will use language models trained or fine-tuned against a library of known C-to-Rust translations. The aim is to produce Rust that expresses the intent of the original program using appropriate Rust abstractions, rather than mechanically reproducing C syntax.

Validation will check that the Rust implementation behaves like the C source. The project will explore fuzz testing alongside more formal approaches to equivalence checking.

Debugging and repair will analyse failed validations, locate likely translation faults and attempt targeted corrections using symbolic program-repair techniques.

Here the language model is only one component in the system. Generated code should be treated as untrusted until there is evidence that it preserves the desired behaviour. This is the same principle I apply to agentic software development more generally: generation is useful, but it needs to sit inside a system of constraints, feedback and verification.

Applying the research to Ubuntu

Research into code translation can look successful when evaluated only against small programs or carefully selected benchmarks. Real repositories are less accommodating.

Long standing repositories often accumulate build-system complexity, platform-specific behaviour, unusual error paths and assumptions that may not be obvious from an individual function. Security-sensitive software also tends to contain exactly the low-level operations that are hardest to translate cleanly.

As part of the collaboration between Canonical and the University of Bristol, the project will target AppArmor and snap-confine as industrial case studies. Both are critical to Ubuntu’s security posture, and provide a substantially harder test than isolated translation examples. They will help us evaluate whether the techniques can cope with the structure and constraints of mature production...