Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Translating All C to Rust (TRACTOR)

darpa.mil

Post reply on HN
Print view View original

261–270 of 403 posts

Re: Translating All C to Rust (TRACTOR)

#261

Post by Y_Y »

pjmlp wrote: post #248
nanolith wrote: post #27

I'm personally not a fan of "rewrite the world in Rust" mentality, but that being said, if one is planning to port a project to a new language or platform, mechanical translation is a poor means of doing so. Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece. Don't build a castle in the sky, because it will never reach the ground. If you've…

Modern C still has the same security exploits in arrays and strings as Classical C, nothing changed in 50 years.

The programmers have changed, the machines have changed, the literature has changed, the compilers have changed a lot. You can still write and run the old insecure code, but you'll get warnings and hit stack canaries and your colleagues will gasp at you and your merge requests will be rejected.

Re: Translating All C to Rust (TRACTOR)

#263

Post by the8472 »

sans-seraph wrote: post #92

I have been aware of this proposed initiative for some time and I find it interesting that it is now becoming public. It is a very ambitious proposal and I agree that this level of ambition is appropriate for DARPA's mission and I wish them well. As a Rust advocate in this domain I have attempted to temper the expectations of those driving this proposal with due respect to the feasibility of automatic translation fro…

> In order to translate C code to Rust code that missing information must be produced by someone or something.

If you don't go for preserving the formal semantics of C code and instead only require the test-suite to still pass after translation that can provide a lot of wiggle room for the translation. This is how oxidation projects often work in practice. Fuzzers can also help with generating additional test data to get good branch coverage.

Re: Translating All C to Rust (TRACTOR)

#264

Post by pjmlp »

Y_Y wrote: post #261
pjmlp wrote: post #248

Earlier quoted context omitted.

Modern C still has the same security exploits in arrays and strings as Classical C, nothing changed in 50 years.

The programmers have changed, the machines have changed, the literature has changed, the compilers have changed a lot. You can still write and run the old insecure code, but you'll get warnings and hit stack canaries and your colleagues will gasp at you and your merge requests will be rejected.

Meaningless changes, as proven by the CVE database, or the kernel corruption by a bad pointer caused by Crowdstrike.

Re: Translating All C to Rust (TRACTOR)

#265

Post by pjmlp »

nanolith wrote: post #207
pdimitar wrote: post #202

Earlier quoted context omitted.

> In reality one can obviously do a lot of things to improve safety in C/C++. That's not "in reality", that's "in theory". Because in actual reality, people still write the good old buffer overflow bugs to this day. I don't think anyone reasonable is disputing that we indeed can improve C/C++ programming. The argument of myself and many others like myself is: "a lot can be done but for one reason or another it is STI…

> That's not "in reality", that's "in theory". Because in actual reality, people still write the good old buffer overflow bugs to this day. That's because while the technology exists, it is not widely communicated. That's not a fault of C, and that's not something that any language can solve. > Explain why this has not been done yet. See above. The technology to make C and C++ safer is not yet widely used. But, it ex…

The proven fact that the said technology has failed its purpose, as the C and C++ culture keeps resisting its adoption, is the fact that all CPU vendors are now integrating hardware memory tagging as the ultimate weapon against memory corruption exploits.

Solaris has already been doing it since 2015, ARM more recently, we have Microsoft putting the big buckets into CHERI (including custom FPGA boards for testing), the new CoPilot+ PCs architecture with Pluton, and while AMD/Intel attempts weren't quite right like MPX, they will surely do something for x64 as well.

Re: Translating All C to Rust (TRACTOR)

#266

Post by swiftcoder »

0cf8612b2e1e wrote: post #89
psychoslave wrote: post #61

Earlier quoted context omitted.

Ok, but if it's like 90% of small projects can use it as direct no pain bridge, that can be a huge win. Even if it's "can handle well 90%" of the transition for any project, this is still interesting. Unlike cars on the road, most code transition project out there doesn't need to be 100% fine to provide some useful value.

Even if every project can only be 90% done, that’s a huge win. Best would be if it could just wrap the C equivalent code into an unsafe block which would be automatically triaged for human review. Just getting something vaguely Rust shaped which can compile is the first step in overcoming the inertia to leave the program in its current language.

c2rust exists today, and pretty much satisfies this. I've used it to convert a few legacy math libraries to unsafe rust, and then been able to do the unsafe->safe refactor in the relative comfort of the full rust toolset (analyser + IDE + tests)

There is real utility in slowly fleshing out the number of transforms in a tool like c2rust that can recognise high-level constructs in C code and produce idiomatic safe equivalents in rust

Re: Translating All C to Rust (TRACTOR)

#267

Post by Avamander »

9659 wrote: post #157
fsckboy wrote: post #125

Earlier quoted context omitted.

in this case it seems to me the hard task that DARPA has chosen is to get me to forget how much they spent on pushing Ada.

ada does not require 'pushing'. once the maturity of the users advances to a sufficient point, then ada is the only solution. "ada. used in creating reliable software since 1983" when i first saw ada, i didn't understand the why. now i understand the why, but ada is effectively gone. -- old fortran / C / Assembly programmer

Oh, it's around, but laypeople never see those codebases.

Re: Translating All C to Rust (TRACTOR)

#268

Post by Avamander »

matheusmoreira wrote: post #197
atiedebee wrote: post #174

Earlier quoted context omitted.

> Who cares if your program actually works as intended? My optimization is legal according to the standard, it's your program that's relying written to exploit loopholes". If your program invokes undefined behaviour, it's invalid and non-portable. Out of bounds array accesses are UB, yet a program containing them may just happen to work. It won't be portable even between different compiler versions. The C standard is…

If undefined behavior is invalid, then reject the program instead of "optimizing" it. This "oh look undefined behavior I'm gonna turn the entire function into a no-op" nonsense is completely unacceptable. It's adversarial and borders on malicious. Null pointer check deletion can turn bugs into exploitable vulnerabilities.

> This "oh look undefined behavior I'm gonna turn the entire function into a no-op" nonsense is completely unacceptable. It's adversarial and borders on malicious.

You significantly underestimate how much UB people write and overestimate the end-result if the current approach would not be taken.

Re: Translating All C to Rust (TRACTOR)

#269

Post by Avamander »

Y_Y wrote: post #261
pjmlp wrote: post #248

Earlier quoted context omitted.

Modern C still has the same security exploits in arrays and strings as Classical C, nothing changed in 50 years.

The programmers have changed, the machines have changed, the literature has changed, the compilers have changed a lot. You can still write and run the old insecure code, but you'll get warnings and hit stack canaries and your colleagues will gasp at you and your merge requests will be rejected.

All that has changed but we still got the libcue code execution bug.

I could not find an open-source static analyzer (including -analyzer) that would actually pick up the flaw before someone tries to exploit it.

And that's a simple example.

We can't tame the dragon C is, empirically nobody can.

Re: Translating All C to Rust (TRACTOR)

#270

Post by nanolith »

pjmlp wrote: post #248
nanolith wrote: post #27

I'm personally not a fan of "rewrite the world in Rust" mentality, but that being said, if one is planning to port a project to a new language or platform, mechanical translation is a poor means of doing so. Spend the time planning better architecture and designing a better software system, and find a way to replace it piece by piece. Don't build a castle in the sky, because it will never reach the ground. If you've…

Modern C still has the same security exploits in arrays and strings as Classical C, nothing changed in 50 years.

Bounded model checking has changed things. C on its own can't solve these problems. Likewise, Rust on its own -- while it can solve memory errors -- can't demonstrate safety from all errors that lead to CVEs.

Practical formal methods using a tool like CBMC can make C safer. The existing code base can be made safer without porting it to a new language or using experimental mechanical translation. This isn't just something for C. Such tools exist for many languages now, including Rust, so that even Rust can be made safer.

Post reply on HN