Countering Trusting Trust Through Diverse Double-Compiling (DDC)

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.

Well, if you are unsure if you can trust the second compiler (e.g. you didn't write it, audit it, bootstrap it yourself) you can just add a third (slightly more trustedworthy) compiler.

After that the infinite stack of turtles will take over and make sure it is asymptotically trustworthy.