5 ms·
Seems to be like the best way to mitigate this would be to write a rust interpreter in assembly and use that to compile the compiler.
by foota 10y ago
Seems to be like the best way to mitigate this would be to write a rust interpreter in assembly and use that to compile the compiler.
- kibwen 10y agoIt doesn't need to be in assembly, you could write a compiler/interpreter in any non-Rust language and use that to verify the compiler binary from source (unless you think that someone has already inserted a backdoor into your X-lang compiler with the specific intent of inserting backdoors into the Rust compiler, which is a bit of a stretch (especially if you use a compiler that completely predates Rust, e.g. a version of GCC from 2005)). And even writing your compiler in assembler doesn't provide assurance that your CPU itself hasn't been compromised. :P
- Gankro 10y agoI still believe in the dream of the mythical Graydon Backdoor in OCaml. No one could even be mad, it would be so good.
- kibwen 10y agoEventually it will be revealed that he even bothered to politely document the backdoor in the Rust reference manual, confident that nobody would ever, ever believe anything found in the reference manual.
- steveklabnik 10y agoIIRC, last time he was asked about this, he said something like "I consider it a great compliment that someone thinks I'm smart enough to have done this, I assure you I am not."
- foota 10y agoTil the google results for "Graydon Backdoor" are... interesting.
- qwertyuiop924 10y agoWhat is the OCaml Graydon Backdoor? I can't find any reference to it.
- Manishearth 10y agorustc was originally written in OCaml by Graydon Hoare. Hypothetically, Graydon could have inserted a trusting trust attack in the ocaml compiler that would also insert a version of itself inside rustc. Highly unlikely; very hard to do, but ... possible.
- Gankro 10y agoThe more impressive part is: that manages to self-preserve across hundreds of Rust language/compiler versions with wildly varying designs and semantics all the way up to today's version.
- steveklabnik 10y agoNB:hundreds is literal here. A little over 300 last I checked.
- Gankro 10y agoAbout this many: https://github.com/rust-lang/rust/blob/235d77457d80b549dad3ac36d94f235208a1eafb/src/snapshots.txt https://github.com/rust-lang/rust/blob/235d77457d80b549dad3a... (This file is no longer in master because the compiler bootstraps from the previous stable release; too lazy to accurately isolate the last time it was updated)
- steveklabnik 10y agoYup, plus since you need to compile three times on each one, to do the bootstrapping...
- duaneb 10y agoThat would be some gorgeous code to maintain itself successfully all this time.
- drvdevd 10y agoOne of the interesting points raised in the original Trusting Trust paper was exactly this - that next level of trust can again be subverted via microcode modification, and so on and so forth. I really don't view Trusting Trust (in the original paper) as an attack so much as a philosophical question being asked about trust in general and the way it propagates through supply chains. It's almost a paper more on economics than anything else..
- Manishearth 10y ago> I really don't view Trusting Trust (in the original paper) as an attack so much as a philosophical question being asked about trust in general Yep. This was the original intention of the talk/paper; it was about _trust_, not attacking compilers. Attacking compilers is just a super cool example that was used.
- rudolf0 10y agoOnce intelligence agencies start backdooring microcode (especially in a way that chip manufacturers can't detect), I'm throwing out my computer and living in the woods.
- oldsj 10y agoHow would you know if they did?
- rudolf0 10y agoI suspect someone somewhere would eventually find out.
- SomeStupidPoint 10y agoIf you're in a situation where it matters, the safe assumption would be Intel chips have been backdoored a while, and others likely are too.
- bluejekyll 10y ago