DARPA: Translating All C to Rust (TRACTOR)

1

For those who care about US government things:

After more than two decades of grappling with memory safety issues in C and C++, the software engineering community has reached a consensus. It’s not enough to rely on bug-finding tools. The preferred approach is to use “safe” programming languages that can reject unsafe programs at compile time, thereby preventing the emergence of memory safety issues.

The TRACTOR program aims to automate the translation of legacy C code to Rust. The goal is to achieve the same quality and style that a skilled Rust developer would produce, thereby eliminating the entire class of memory safety security vulnerabilities present in C programs. This program may involve novel combinations of software analysis, such as static analysis and dynamic analysis, and machine learning techniques like large language models.

Additional information is available in the TRACTOR Special Notice on SAM.Gov.

Not sure that using LLM's is a great way to achieve their goals, but with that said -- I'm sure there are people who are far smarter than I pulling the levers there.

PS. I've already seen some people be really angry about this on other forums/platforms, so .. be prepared for that.

3 Likes
2

Having worked in government. People are just people at every level. I've rarely encountered someone particularly more intelligent than myself (and I don't claim any particular cleverness), and when I did they never were in management positions.

11 Likes
3

Sorry, can you tell me what is wrong with the project? And why are people angry? (https://www.darpa.mil/program/translating-all-c-to-rust is inaccessible to me)

4

Personally I don't think there's anything wrong with the project. It's more a question of "how big is the code base" and "is this really the best use of resources"? I'd wager a guess that the reason they want to use an LLM is because the amount of code they want to port is substantial, so they want to automate the process. If it is the case that the code base is huge; then I'm not sure it's a good idea to use an LLM to speed up the process.

But that's just speculation on my part. It could be that these projects have a history of having lots of memory safety issues that Rust would have caught, in which case it would (potentially) be worth the resources. Anyway, I'm sure we'll learn more about whether this project was a success or a disaster in a few years.

With regards to the anger part: There's a perception, among some non-Rust developers, going around that a defining characteristic of Rust developers is that they think that everything should be rewritten in Rust.

There's even a conspiracy theory that the Rust Foundation's 501 organization type was chosen so it can conduct lobbying. The implication being that the Rust Foundation is behind government recommendations to move toward memory safe languages. (Big Borrow-Checker, if you will).

Whenever these types of stories end up on certain sites, there's a small, but vocal, group of people who get riled up, and - at least in my experience - it's better to just stay away until they have cooled down a little.

7 Likes
5

Ah, governments governmenting.

Using an extremely complicated, stochastic black box to translate existing, mission-critical code to a new language is a terrible, terrible idea.

"Rewrite it in Rust" works wonderfully – if:

  • the rewrite is by someone who masters C, C++, and Rust
  • knows the specific requirements and caveats associated with the domain
  • deeply understands the problems associated with the current technology/language/solutions/idioms
  • knows how to fix them at the high level
  • and knows how to implement those high-level ideas correctly, idiomatically, and efficiently in the new language.

If the rewrite happens by the typical, know-it-all, LLM-fanatic, tunnel-vision grad student (or God forbid, professor) who only ever used C, and is an enjoyer of furiously dancing raw pointers and loud proclamations on how "sufficiently experienced" programmers never actually make memory management errors, then what will end up happening is that the oh-so-glorious rewrite will be rushed to completion by sprinkling the code full of unsafe, transmutes, and other dubious practice, then declaring that Rust is "too limiting", and they'll end up with a huge pile of unreadable, un-idiomatic, bug-ridden code, that contains all the original soundness holes, and some more logic errors – thanks to the subtle semantic and syntactic differences between the languages.

I wish them best of luck for that sort of journey.

19 Likes
6

This will be a giant failure. Oh and using LLM as well. I will just grab some popcorn and wait for it's inevitable explosion.

6 Likes
7

Assuming a worst case scenario, this could be the worst thing to happen to Rust’s image. We end up with billions of lines of rewritten Rust code that is full of soundness and logic bugs, and that no one understands.

2 Likes
10

The obvious gut reaction is that TRACTOR is doomed to fail. People have been working on such static analysis for decades and so far have not produced anything that reliably finds faults (let me know how I can apt-get it if they have) never mind translate to some other totally different language. Meanwhile my experience is that AI bots are not very good at writing Rust.

I'm wondering why the aim is translation to Rust? If the static analysis can reliably find problems in C and the LLM can reliably fix it why not just rewrite into new C code? After all why do we need all the checking that Rust does if the analysis/LMM can do it?

I guess when governments have such ideas there is money thrown at it and a clamour for researchers to grab some of it. Someone researching static analysis for years has tacked the "LLM" keyword onto a grant application so they can continue their work. Hopefully something useful will come out of it.

7 Likes
12

The US government has a goal to get rid of memory-unsafe languages in code it depends on; that means that, if it's working on fixing things, it wants to translate C to Rust or Ada as part of the fix.

It sounds to me like this research is less about "can the LLM fix the code", and more "can the LLM translate from C to Safe Rust such that feedback from the compiler (including allow-by-default lints) can then be used by an LLM to debug the code fully", and it also looks like one of DARPA's long-shot bets[1], with two possible beneficial outcomes:

  1. DARPA gets a machine that can translate C code to Safe Rust in a useful fashion, where a human then needs to debug the Safe Rust.
  2. DARPA gets a machine that can take buggy Rust code and fix it, using the compiler as a feedback tool to identify where it needs fixing.

  1. DARPA funds some projects on a "there is an infinitesimal chance of success, but if you succeed, it's a big deal" basis. Silent Talk is an example here - very unlikely to succeed, even at the beginning, but if you could hold a radio conversation without sound, that'd be a huge deal for special operations forces. ↩︎

6 Likes
14

Strangely enough that already works to some extent. A while back I asked an AI bot to translate a couple of pages of gnarly C into Rust and it did so. Including handling some hairy C macros. There were a couple of little errors I had to fix to get it to compile.

I can sort of imagine it could tackle compilation errors so as to get a clean compile. But would that be less buggy or more buggy? To determine that it would have to have total understanding of the requirements as well.

1 Like
15

That's why I think this a long-shot bet, not a project expected to succeed. It has a small but reasonable chance of succeeding (to the point where it could, for example, translate the Linux kernel from C into acceptable Safe Rust), and a tiny chance of succeeding so well it can produce you a program with a subset of the original set of bugs. Both of those are valuable if possible.

And I put this project in the same category as Silent Talk for a reason - it's one where the failure chance is high enough that industry won't fund it, where the success outcomes are highly valuable if they're possible at all, and thus DARPA funding will either get a highly valuable success outcome that wouldn't have happened otherwise, or an expensive failure that only government funding can tolerate.

8 Likes
16

I sense many people in this forum may not understand what a Special Notice is or why DARPA issues them, and perhaps haven't clicked through to the government website to actually read the notice (to be fair, it's not totally obvious that the real notice is in the "Attachments/Links" section, and isn't the front text).

How US federal government agencies like DARPA fund research

DARPA doesn't do its own research projects: it funds private companies, universities and research groups. These entities range from obvious (defense contractors) to surprising to obscure. If anyone is already working on translating C to Rust, they should be interested in this, since it is an indicator that DARPA is interested in funding that kind of research.

But this is not a funded project yet. Before a project can be funded, DARPA has to evaluate proposals and choose one or more to fund, and before they can evaluate proposals people have to write proposals. Before people can write proposals, DARPA needs to issue a call for proposals, which will contain a lot of information about the funding opportunity, budget, expected timeline, specific research areas DARPA is interested in funding, that kind of thing.

Before requesting proposals, DARPA may go through one or more rounds of requesting additional information, either from the US research community at-large or from specific entities they are interested in hearing from. This is for DARPA to acquire information they need to scope and write the eventual funding opportunity.

We're not at that stage yet either. This is an invitation to register for an event for potential proposers in the Washington, DC area. It's basically saying, "hey, we're interested in this research area, let's get a bunch of people working in it in the same room and see if any interesting synergies pop up."

There's no funding for this research yet, there's no taxpayer money going to LLMs to translate C to Rust. This is a party in Northern Virginia for people who might have thoughts on the topic, to meet other like-minded people, to maximize the chances of getting the right brains together to write a winning proposal that will maximize the chances of performing some interesting research in an area that the defense industry direly needs interesting research.

Performing research doesn't mean you know the answer. This isn't that kind of program. This is a program about stimulating programming language, LLM, and automated translation research. The research may find what many people are saying, that automated translation of C to Rust is not feasible and LLMs don't work. But the point is to actually do the research, not just speculate. Research begets more research and even if this program doesn't result in an automated C to safe Rust transpiler, it may lead to improvements in some other area.

Neither are they. That's what makes it research. Note the "may". DARPA is interested in research in this area. They have not vowed to send money to groups that use LLMs nor to reject proposals that don't use LLMs. This funding opportunity will doubtless bring in people from different research areas, not all of them working on LLMs. If the best proposal makes a case for automated translation of C to Rust without using LLMs at all, it'll probably be funded.

23 Likes
17

Conversion of C code to unsafe Rust, like c2rust does, is already possible, but such code is hard to read and isn't safer.

Naively translated code could be cleaned up, and made safer, but that requires figuring out many more details about the code, such as whether any given pointer is for a single object or an array, and how the length of that array is tracked.
There are no hard rules for such things in C, so a traditional rule-based code transpiler can't handle that automatically. However, use of LLMs for problems like this seems sensible. LLMs can "read" the code, variable names, and code comments, to deduce/translate this information into code annotations/metadata that can improve quality of translated code.

It's a hard problem, and LLMs are fiddly and imprecise, but the problem doesn't seem impossible.

9 Likes
18

This is basically my position as well. Any reasonable proposal isn't going to claim that an LLM can do the translation on its own — it's going to be a combination of traditionally driven static analysis for objective matters and asking ML models about more qualitative properties. Microsoft's SAL annotations or any of various other "C plus context" systems add more context to C shaped APIs that make it easier to guess the equivalent Rust API, and giving reasonable intuition on par with a dev getting introduced to the code is a task I'd be comfortable asking LLMs to do.

I'm maybe not so confident in marking any translated source as safe if it uses any unsafe, but as I understand, the ideal goal is that any TRACTOR translated code wouldn't. If TRACTOR can even clean up 30% of c2rust unsafe into purely safe code — which is imo a conservative estimate of how much code would be following simple shared XOR mutable patterns already — then it's a win in my book.

Hoping for idiomatic output is perhaps a bit ambitious, but safe and straightforward seems reasonable.

8 Likes
19

While I'm pretty bearish on LLMs in general, translation of idiomatic text to different idiomatic text is pretty much the best possible case for them, and is a functionality that effectively didn't exist before (with asterisks)

When combined with compiler feedback, enforcing safe Rust, unit tests, human review, and whatever other analysis they can come up with, this may have a chance where this has failed many times before.

To be fair to them, this isn't completely untrue... but it's also true to some extent of every language. It's more just that it seems to be actually happening with Rust, eg binutils, fish, every JavaScript ecosystem tool....

9 Likes
20

There is some mindset toward making memory safe languages mandatory as articulated very well by Caroles10¢

1 Like
21

AFAIK this is the closest we've gotten to that so far: Press Release: Future Software Should Be Memory Safe | ONCD | The White House

So far as I understand it, there's not really much that can be done to actually mandate a language or something similar, 1st amendment and all.

I'd perhaps hope instead that we see something like with construction engineering where professional standards are defined and at least some leadership/gatekeeping role held legally responsible for security (at least), but there's plenty of obvious issues with that too.

1 Like
22

Interesting. Does the 1st amendment actually say anything about materials and tools used in engineering and such like?

For example using lead in solder was deemed dangerous so the electronics industry was regulated to not use it. I would have imagin that if use of C or whatever was deemed a practice detrimental to society it could be regulated in the same way.

Mind you, as far as I can tell it's hopeless, there was a time when it was mandated that the Ada language be used for all government (or at least defence) projects. That did not last long.

1 Like
23

Just imagine....

A few years down the road the TRACTOR project actually manages to come up with something that works.

One morning Linux Torvalds wakes up and finds a pull request on the kernel (or does he get patches in email?):

Author: TRACTOR
Title: Total rewrite of kernel in Rust for security reasons.

I'm sure Linus would find some acceptable language to frame is response...:slight_smile:

More seriously, what would we do? All of a sudden there exists a working Linux kernel in Rust. Likely the kernel devs are still mostly still C heads. Even if they know or can pick up Rust they are still presented with a mind bendingly huge code base that nobody knows anything about.

  1. Do they throw all their C code away and simply carry on in Rust? Seems like an impossibly hard challenge. It would certainly halt progress for ages as they get their heads around it.

  2. Does the Rust version become a new project with a whole new set of Rust enthusiast devs and some devs migrating from original Linux? Also seems unlikely, they would have the same issues getting to understand why they have.

  3. What about distros and users? Do they jump ship to the new Rust kernel?

Of course questions like this apply to thousands of other projects.

Seems like all these projects would get hijacked or at least forked. But the new forks have no maintainers. How would this be tenable?

5 Likes
24
  1. The kernel devs just keep doing what they do in C and use Tractor to process each release.
2 Likes