3 ms·

I'm having trouble understanding this bit: > In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code

I'm having trouble understanding this bit: > In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable. Can someone explain this step by step? Which compiler compiles which source?

peterwaller 12y ago
So you have your (possibly tainted at the binary level, see "Reflections on trusting trust") compiler, let's call it [A]. You take source code to a compiler [GCCsource], which for the purposes of this we'll say we can trust (because at least we can read the source, IOCCC notwithstanding). The problem is that if you Compile [GCCsource] with [A] to make [GCCWithA], [GCCWithA] may be tainted if [A] is tainted. The fix is to make GCC produce reproducible builds. Then you compile [A]([GCCsource]) -> [GCCWithA] and the critical step is this: [GCCWithA]([GCCsource]) -> [GCCWithAWithA]. If [GCCWithA] makes reproducible builds, then [GCCWithX] should make bit-identical outputs with [GCCWithA]. If it doesn't, then you can tell that there are shenanigans going on. So you do [A]([GCCsource]) -> [GCCWithA]; [GCCWithA]([GCCsource]) -> [GCCWithAWithA] And then [B]([GCCsource]) -> [GCCWithB]; [GCCWithB]([GCCsource]) -> [GCCWithBWithB] You compare [GCCWithAWithA] with [GCCWithBWithB]. Now you've upped the bar. Not only does an attacker have to put a backdoor in the GCC binary, but now they have to do it to Intel's compiler, and any other compiler capable of compiling [GCCsource]. If the attacker doesn't catch all of these compilers them in exactly the same way, then it will result in a difference to the output.
- jakobegger 12y ago
  Thanks, I understand now.

peterwaller 12y ago

So you have your (possibly tainted at the binary level, see "Reflections on trusting trust") compiler, let's call it [A]. You take source code to a compiler [GCCsource], which for the purposes of this we'll say we can trust (because at least we can read the source, IOCCC notwithstanding). The problem is that if you Compile [GCCsource] with [A] to make [GCCWithA], [GCCWithA] may be tainted if [A] is tainted. The fix is to make GCC produce reproducible builds. Then you compile [A]([GCCsource]) -> [GCCWithA] and the critical step is this: [GCCWithA]([GCCsource]) -> [GCCWithAWithA]. If [GCCWithA] makes reproducible builds, then [GCCWithX] should make bit-identical outputs with [GCCWithA]. If it doesn't, then you can tell that there are shenanigans going on. So you do [A]([GCCsource]) -> [GCCWithA]; [GCCWithA]([GCCsource]) -> [GCCWithAWithA] And then [B]([GCCsource]) -> [GCCWithB]; [GCCWithB]([GCCsource]) -> [GCCWithBWithB] You compare [GCCWithAWithA] with [GCCWithBWithB]. Now you've upped the bar. Not only does an attacker have to put a backdoor in the GCC binary, but now they have to do it to Intel's compiler, and any other compiler capable of compiling [GCCsource]. If the attacker doesn't catch all of these compilers them in exactly the same way, then it will result in a difference to the output.

jakobegger 12y ago
Thanks, I understand now.