Translating All C to Rust (TRACTOR) • Hacker News Board

Re: Translating All C to Rust (TRACTOR)

#211

Post by commodoreboxer » Wed, Jul 31, 2024, 12:54 AM UTC

akira2501 wrote: post #151

timeon wrote: post #144

Earlier quoted context omitted.

> To do anything interesting you will require unsafe blocks. This will not get you very much. This is not true.

> This is not true. Burying unsafe blocks in unevaluated cargo modules does not make this true. You're just taking the original problem and sweeping it under the rug.

You can do tons of stuff with purely safe Rust. The main things that you can't do are FFI, making self-referential structures, and dereferencing raw pointers.

And unsafe isn't a problem. It's a point of potential danger to be heavily audited, tested, and understood. Having the entire language unsafe by default is an obviously worse situation. This is throwing the baby out with the bathwater, like rallying against seat belts because you can still die while wearing one. An improvement is still an improvement. I don't understand why people criticizing Rust tend so heavily to let perfect be the enemy of good.

Re: Translating All C to Rust (TRACTOR)

#212

Post by nanolith » Wed, Jul 31, 2024, 1:17 AM UTC

pdimitar wrote: post #210

nanolith wrote: post #207

Earlier quoted context omitted.

> 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…

> That's not a fault of C, and that's not something that any language can solve. If you say so. Rust clearly does, and before you go saying "but `unsafe` exists!" I'll have to remind you that (1) scarcely any Rust devs reaches for that and (2) it still keeps quite a lot of guarantees and only relaxes some . Some, not all. Not even most. > It's laudable that you wish to rid the world of memory errors. I want to normal…

> Rust clearly does

Until it exists at the kernel layer, the firmware layer, the runtime library layer, and the application layer, these issues still exist. CVEs come out weekly for memory errors in Linux, in firmware, in operating system libraries, and in application libraries. We need to think beyond rewriting code in one language or platform, and instead think about technologies that we can apply to all languages and platforms, including C and Rust.

> I am saying that Rust clearly can get us further than we are right now.

As can bounded model checking, without having to teach developers a new language with new idioms.

> If there's something even more accessible, less verbose, and with not such a cobbled together Frankenstein async implementation...

Indeed there is. Reach for the bounded model checker that works with your existing language or platform. Pour over the manual, and look at existing practical examples.

If you like Rust, feel free to use it. But, if you prefer C/C++, Pascal, Ada, Python, C#, Java, or Modula2, that's fine. Either use an existing bounded model checker for that language or port CProver / GOTO to that platform. Rust developers ported CProver to Rust via Kani, because they also recognize that writing safer code can't be done by language alone.

I don't think it's necessary to push people to use different languages or platforms to write safer code. They just need to use or port existing tooling and learn safer coding practices. If I come at firmware developers or old school OS developers with "we need to use Rust", the conversation is immediately shut down and I'm considered a fool. If, instead, I show them tooling that allows them to maintain their existing code base and make it safer, I get much further.

Re: Translating All C to Rust (TRACTOR)

#213

Post by lmm » Wed, Jul 31, 2024, 1:27 AM UTC

sqeaky wrote: post #140

Calavar wrote: post #47

Earlier quoted context omitted.

> today cars drive themselves You can attach about a hundred asterisks to that. If anything, I think self the failure to hit L5 driving after billions of dollars and millions of man hours invested is probably reflective of how automatic C to Rust translation will go. We'll cruise 90% of the way, but the last 10% will prove insurmountable with current technology. Think about the number of C programs in the wild that r…

This is the exact formulation of the argument before computers beat humans at chess, or drew pictures, or represented color correctly, or... Self driving cars will be solved. There is at least one general purpose computer that can solve it already (a human brain), so of a purpose built computer can also be made to solve it. In 10 (or 2 or 50 or X) years when Chevy, Ford, and others are rolling out cheap self driving…

> This is the exact formulation of the argument before computers beat humans at chess, or drew pictures, or represented color correctly, or...

Which are things that took 20 or 50 years longer than expected in some cases.

> I think you picked self driving cars just because it is a big and only partially solved problem. One could just as easily pick a big solved problem or a big unstarted problem and formulate equally bad arguments.

But C to Rust translation is a big and only partially solved problem.

Re: Translating All C to Rust (TRACTOR)

#214

Post by wffurr » Wed, Jul 31, 2024, 1:33 AM UTC

0xbadcafebee wrote: post #173

wffurr wrote: post #69

Earlier quoted context omitted.

But even proficient C and C++ programmers continue to produce code with memory safety issues leading to remote code execution exploits. This argument doesn’t hold up to the actual experience of large C and C++ projects.

They aren't trying to prevent them. It's trivial to prevent them if you actually put effort into it; if you don't, it's going to be vulnerable. This is true of all security concerns.

No True C Programmer writes code with buffer overflows in it. It's pretty clear this is not a serious take.

Re: Translating All C to Rust (TRACTOR)

#215

Post by astrange » Wed, Jul 31, 2024, 1:39 AM UTC

rectang wrote: post #180

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…

The C standard with its extensive undefined behavior causes programmers and compiler writers to be at odds. In a sane world, "undefined behavior" wouldn't be assumed to mean "the programmer must have meant for me to optimize this whole section of code away". We aren't on the same team, even if I believe that all parties are acting with the best of intentions. I don't feel that the Rust language situation incentivizes…

A funny thing about this problem is that it gets worse the more formally correct your implementation is. Undefined behavior is undefined, so it's outside the model, and if your program is a 100% correct implementation of a model then how can it know what to do about something outside it?

But I don't think defining all behavior helps. The defined behavior could be /wrong/, and now you can't find it because the program using it is valid, so it can't be detected with UBSan.

Re: Translating All C to Rust (TRACTOR)

#216

Post by astrange » Wed, Jul 31, 2024, 1:41 AM UTC

bigstrat2003 wrote: post #193

derdi wrote: post #176

Earlier quoted context omitted.

> undefined behavior gives the compiler leeway in deciding what a program does, so the more undefined behavior a C program invokes, the easier it is to translate its code to rust. You assume that the compiler can determine what behavior is undefined. It can't. C compilers don't just look at some individual line of the program and say "oh, that's undefined, unleash the nasal demons". C compilers look at code, reason t…

I (not the person you are replying to) do understand that's how compilers interact with UB. However, a wealth of experience has shown us that the assumption "UB doesn't occur" is completely false . It is, in my opinion, quite irresponsible for compiler writers to continue to use a known-false assumption when building the optimizer. I don't really care how much speed it costs, we need to stop building software on a sh…

Soon (or actually, already) we'll have MTE and CHERI, and then that C undefined behavior will be giving you security improvements as well as speed improvements.

Can't design a system that 100% crashes on invalid behavior if you've declared that behavior is valid, because then someone is relying on it.

Re: Translating All C to Rust (TRACTOR)

#217

Post by astrange » Wed, Jul 31, 2024, 1:42 AM UTC

the8472 wrote: post #107

mike_hearn wrote: post #10

That sounds ... hard. Especially as idiomatic Rust as written by skilled programmers looks nothing like C, and most interesting code is written in C++ anyway. Isn't it equivalent to statically determining the lifetimes of all allocations in the C program, including those that are implemented using custom allocators or which cross into proprietary libraries? There's been a lot of research into this sort of thing over…

Write tests for your C code. Run c2rust (mechanical translation), including the tests. Let a LLM/MCTS/verifier loop go to town. Verifier here means it passes compiler checks, tests, santiziers and miri. Additional training data can be generated by running mrustc or by inlining unsafe code (from std/core/leaf crates) into safe code and running semantics-preserving mechanical refactorings on the code. This can be close…

You could already use ASAN + UBSan, or Frama-C.

Re: Translating All C to Rust (TRACTOR)

#218

Post by defrost » Wed, Jul 31, 2024, 1:43 AM UTC

wffurr wrote: post #214

0xbadcafebee wrote: post #173

Earlier quoted context omitted.

They aren't trying to prevent them. It's trivial to prevent them if you actually put effort into it; if you don't, it's going to be vulnerable. This is true of all security concerns.

No True C Programmer writes code with buffer overflows in it. It's pretty clear this is not a serious take.

FWiW "True C Programmers" delibrately coded "buffer overflows" all the time back in the day.

The practice of using variable sized structures that began with type and size info and ended with a char[1] was commonplace.

https://hex-rays.com/blog/igors-tip-of-the-week-94-variable-...

Good True C Programmers had guard rails | canary bytes | etc. to detect and avoid actual buffer overflow (into unallocated memory) rather than technical buffer overflow (reading|writing past the end of a char|byte array).

Re: Translating All C to Rust (TRACTOR)

#219

Post by infamouscow » Wed, Jul 31, 2024, 1:44 AM UTC

Anyone interested in this should apply, but also look into one of the small software consultants that does a lot of government contracting. Those consultants will likely also be involved in this and more potential opportunities to work on this. Also, the private sector pays (much) better and you'll have liaisons to handle most of the bureaucratic nonsense that accompanies a government job, especially within the morass of the DoD. Going into this without being prepared for immense political nonsense will not be effective.

Re: Translating All C to Rust (TRACTOR)

#220

Post by rustcleaner » Wed, Jul 31, 2024, 1:45 AM UTC

Ah! Now's my chance to cheaply break into the dev field by becoming an expert Rust-all-the-C fairy who can flutter into high liability industries and get paid big bucks rebuilding the wheel into a memory-safe wheel!

(I'm only being half-facetious, I fear I may never break in!)