4 ms·
If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
by blueflow 5y ago
If we would write some code in rust, compile it to, for example, x86_64. And then de-compile it to C. It would be perfectly memory-safe C code, right?
- thargor90 5y agoI would guess that writing a decompiler that gets c semantics 100% correct is also really hard. Think about inline assembly, memory barriers, etc. I don't think this would work, unless the c file just contains inline assembly.
- vnorilo 5y agoSome architectural/program assumptions may not be encoded in assembly or preserved in the asm -> C -> asm roundtrip, especially if the assemblers are for different architectures. The obvious example is pointer word size and memory model.
- josephg 5y agoRust might work reasonably well though, given its compiled with llvm. If not, I'm sure whatever asm structures llvm outputs for rust all have C equivalents. I'd be curious to see the output! It'd be funny decompiling the rust compiler to C, then running it on another platform that way. (Though it would still be, for example, an x86 rust compiler running on arm).
- vnorilo 5y agoStrictly speaking all x86 MOVs would have to decompile to some level of atomic load/stores, because of the ordering guarantees on x86. That's an example of "lost in translation" as we don't know if the original source required ordering or not. x86 cannot express the weakest memory model supported by C.
- pjc50 5y agoYes, but it wouldn't necessarily be readable. And it definitely wouldn't be portable!
- tym0 5y agoIsn't Mozilla doing that? Rust to WASM to C. Edit: Sorry I misremembered, they seem to compile C/C++ code to WASM then back to C: https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again... Although technically the plugins could be written in Rust.
- eatonphil 5y agoLink?
- astrange 5y agoIt wouldn't look much like what you'd expect C to look like. If it did decompile back to idiomatic C it could introduce some kind of aliasing bug along the way that'd make it not so memory safe.
- speed_spread 5y agoThe simpler way to obtain C from Rust would be to use mrustc https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc Not that the C will be much more readable than the dissassembly, but there's a chance less information will be lost.
- shin_lao 5y agoNothing is perfectly memory-safe. Also, not sure I would see the point of this translation?
- MaxBarraclough 5y ago> Nothing is perfectly memory-safe. How about formally verified SPARK code?
- astrange 5y agoIt’s strange that people think if they put the word “formal” in front of something it means it’ll work perfectly.
- MaxBarraclough 5y agoThe guidelines ask that you Please don't post shallow dismissals. Are you aware of the scope of SPARK's assurances? You can't accidentally dereference a NULL pointer in verified SPARK code, for instance.
- astrange 5y agoYes, but that's a quality of SPARK, not of the category of "formal methods" by default. For instance, if you write your own proof and then prove the program meets it, there could still be a logic error in your proof. Also, "in verified code" is a big loophole enough to leave security issues in - for instance a web browser (probably the thing you'd most like to prove security-issue-free) can still overwrite its own memory through things like OS image and font code, JavaScript JITs generating code to an insecure ABI you don't have a model for, syscalls to kernel code that can write back into your memory, etc. Believing "formal" makes things magically correct does seem to be a common problem; it also comes up when people say something has a "formal audit" or needs to get one from someone. How do they "formally" audit it? Are they wearing suits?
- 5y ago
- kalnins 5y agoAs Rust is llvm based, you don't need to compile it to C. Just write a backend that translates LLVM IR to C instead of x86_64. The IR is very C looking, it's probably overly complex. Compiling down to asm, lot of information is lost regarding memory layout etc, so it's not the best source for generating code.