David A. Wheeler’s Page on "Fully Countering Trusting Trust through Diverse Double-Compiling" (Trojan Horse attacks on Compilers) Dissertation

This is the home page for my dissertation "Fully Countering Trusting Trust through Diverse Double-Compiling". In particular:

• Fully Countering Trusting Trust through Diverse Double-Compiling (PDF format) (PhD dissertation)
• Proof #1: ddc.in (prover9 input) ddc.html (HTML result) ddc.xml (XML result) ddc.ps (Proof graph in postscript) ddc.ps (Proof graph in postscript, big format) ddc.pdf (Proof graph in PDF) [with consistency proof using ddc-consistent.in available in cooked, tabular, and original output formats].
• Proof #2: all-repeats.in (prover9 input) all-repeats.html (HTML result) all-repeats.xml (XML result) all-repeats.ps (Proof graph in postscript) all-repeats.ps (Proof graph in postscript, big format) all-repeats.pdf (Proof graph in PDF). [with consistency proof using all-repeats-consistent.in available in cooked, tabular, and original output formats]. Note: On November 18, 2009, I made a small tweak to proof #2. Prover9 approved it, and ivy verified it.
• Proof #3: cP-corresponds-sP.in (prover9 input) cP-corresponds-sP.html (HTML result) cP-corresponds-sP.xml (XML result) cP-corresponds-sP.ps (Proof graph in postscript) cP-corresponds-sP.ps (Proof graph in postscript, big format) cP-corresponds-sP.pdf (Proof graph in PDF) [with consistency proof using cP-corresponds-sP-consistent.in available in cooked, tabular, and original output formats].
• It may be easier to understand prover9 through some other examples. Here is prover9 input to prove that Socrates is mortal, a prover9 input to prove that the square root of 2 is irrational, and prover9 input showing how to easily declare that terms in a list are distinct.
• For the Lisp compilers, I started with the ACL2 work. Here are my modified versions and related materials: NOTES mycompiler.cl mymachine.cl demo-shell.cl demo demo-output
• Using DDC on gcc was tricky. Here's the regen script that recompiled gcc, along with the required makefile additions for gcc. Here's a local copy of gcc-3.0.4.tar.gz. Here is the resulting directory containing gcc 3.0.4 using icc as the trusted compiler, and the resulting GCC is the same as the one in the directory containing gcc 3.0.4 using gcc as the bootstrap compiler.

I'm releasing all of the above under the same licensing conditions as the dissertation itself. That is, you may use, modify, and distribute these works them under the terms of the Creative Commons Attribution-Share Alike (CC-BY-SA) 3.0 U.S. license, the GNU Free Documentation License Version 1.2 or later, or the GNU General Public License (GPL) version 2 or later. If you do not specify, I presume you release any modifications under the same conditions as the original.

A quick word about the consistency models. Why create consistency models? The basic issue is that if you use a set of assumptions that are not consistent in a proof, then using classical logic systems you can prove anything... and that's not good. For example, bad.in presumes blatant contraditions; given this, prover9 can "prove" both some formula "p" and the formula "not p". We can show that our assumptions are consistent by sending them to mace4. If mace4 can build a "model" (a set of assignments to variables, in this case numbers, that together can be met by the assumptions), then we've proven that the assumptions are consistent. The assumptions may not be an accurate model of the world (that's a different issue!), but by doing this we can show that they're consistent. The input to mace4 is simply the set of assumptions (without the goal). Mace4 found models for the assumptions of all three proofs, so the assumptions of each proof are consistent. There are several ways to view the output; I prefer the "cooked" form, but it's your choice. In the "cooked" format, assignments are shown for each constant, for each function (given inputs what is the result), and true/false values for each predicate (prefixed with "-" for false and " " for true). In all cases, you can see that it is possible to make such assignments; it would not be possible to make these assignments if the assumptions were inconsistent.

I find proof graphs very helpful, and I originally planned to include them in the dissertation document. I didn't include them in the final dissertation because they're too hard to read when shrunk to ordinary dissertation page sizes. But feel free to look at the proof graphs. The proof graphs were generated from the prover9 XML files using my "gvizify" program. Each step is shown as a node; an arc from step A to step B indicates that step B was proven using step A. The final step of all proofs is $F, meaning "false". The proofs all take a goal, deny it, and show that there is a contradiction. The step number is shown surrounded by {}. The meanings of the node shapes are:

• Rectangle: Assumption
• (No shape): Clausify
• Ellipse: Ordinary proof step Octagon: Denial (negation of the previous step)

I used OpenOffice.org to write the dissertation, and it worked out very nicely. I developed a OpenDocument template for George Mason University that did nearly all the formatting for me automatically. See my suggestions about how to use OpenOffice.org based on lessons learned while writing this dissertation.

Naturally, I had to go through the dissertation process of George Mason University (GMU).

You can see information on the George Mason University (GMU) process for a PhD in Information Technology. George Mason University's Dissertation and Thesis Services has various information; that includes templates, including my OpenDocument template. There's also a GMU web guide. GMU's Thesis, Dissertation, or Project Guide (Updated Fall 2007) has key details. If you're writing a GMU dissertation you should look at the GMU theses and dissertation FAQ.

You can also view my web page on trusting trust, my book on writing secure programs, FlawFinder, or my home page.