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 software.
Note that this is not a commitment to replace AppArmor or snap-confine with what is generated, rather that we have a vested interest in the software and are keen to see the results.
The most optimistic outcome would be a system capable of translating substantial C repositories into Rust with strong evidence of behavioural equivalence and relatively little manual intervention. The research could also produce better methods for decomposing repositories, stronger validation techniques, reusable translation datasets, improved program-repair tools and a more precise understanding of where automated migration stops being reliable.
Practically yes, but also no. The C pointer aliasing rules limit the optimizations the compiler can apply, since any
int *might point to anyintin scope. It’s even worse than that in the Linux kernel: since it has to be compiled with-fno-strict-aliasing, the compiler has to assume that any pointer can alias any variable in scope.Rust simply disallows mutable aliases full stop, and the compiler prevents them in safe code (you can write them in unsafe code but it’s instantly undefined behavior, which is why unsafe rust is harder to write than C). This can sometimes allow the compiler to optimize in ways that wouldn’t be possible in C.
But in practice the impact of this is pretty close to nil as long as you write smallish functions.