3 ms·
Unless your assembler, loader, OS, or microprocessor is also backdoored :) The original article was really about this -- at the end of the day, you have to tru
by Manishearth 10y ago
Unless your assembler, loader, OS, or microprocessor is also backdoored :)
The original article was really about this -- at the end of the day, you have to trust _someone_. Of course, we more easily trust microprocessors and assemblers over binary blobs, so
> I assume interesting versions of TT would have to avoid this trick
Pretty easy to encode the string literal into some binary format.
Alternatively, serialize and later deserialize the AST with a stable binary serialization mechanism.
A really good version of TT operating on the AST would have to backdoor not only the part where it creates the AST, but also the parts where intermediate state is displayed by the compiler (e.g. where it can dump AST/MIR output).
There are things you can do. As a proof of concept, I didn't bother to do them. My current POC is toothless and I like it that way!
It's cleaner to instead operate at the end of the pipeline; on llvm ir or the generated binary (but it's also harder to write). And if you can insert a trusting trust attack in llvm itself, well, that would be something :)
- dwheeler 10y ago> Unless your assembler, loader, OS, or microprocessor is also backdoored :) True... but it has to be backdoored for that particular system. There are many ways you can make it very unlikely that the other compiler/system is backdoored for the same target. For more information, see my work: http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/
- Manishearth 10y agoOf course :) Great work on DDC, btw, I really enjoyed that paper.
- dwheeler 10y agoThanks!! I hated the idea that there could be an uncounterable attack... so I kept at it until I could show that there is a countermeasure.
- nickpsecurity 10y agoThe simplest being my proposal that was a variation on my scheme for bouncing packets/messages across many non-cooperating, national jurisdictions a decade ago. That is: diversity with mutually-suspicious or competing parties. The hardware and software comes from different people, fabs, and nationalities. Preferably that compete. You run the same verifiable core on all of them with lots of tests for equivalence. Build non-optimizing compiler in that from readable source. Build optimizing one with that. With about 5... esp U.S., French, Russian, Chinese, and Japanese... you should be fine. Add South Korea these days with Samsung hardware. The software doesn't have to come from same countries as hardware. Better if it doesn't. All safety checks on in it with POLA enforced at the least. Shady exploits based on language primitives (esp C's) is why the compilers need to be in safe languages.
- nickpsecurity 10y ago"Unless your assembler, loader, OS, or microprocessor is also backdoored :)" On the lowest level, you can hand-check it with pencil and paper. Per Brinch Hansen used to write the earliest compilers in ALGOL that he type-checked and tested by hand. He'd then write optimized assembly that visibly matched each function or procedure. He claimed the ALGOL still aided correctness plus served as better documentation of algorithms than commented ASM. Far as Rust, one could do it by hand if they skipped safety checks and optimizations. Otherwise, do it in older or randomly acquired stuff highly unlikely to be subverted. Many such devices.