Re: TBTF for 1999-10-05: Offlist

Dave Long (dl@silcom.com)
Wed, 06 Oct 1999 01:42:01 -0700


> Think Open Source guarantees you can know what a program does?
> Think again

At the compiler/source level, this is actually a good argument for
building all your software (including os and tools) from source.
Note that unless tool vendors collude, the cycle of infection breaks:

Lst - Thompson source for /bin/login
Lbt - Thompson-infected /bin/login binary
Tst - Thompson source for toolchain
Tbt - Thompson-infected toolchain binaries, as opposed to:
Tbc - clean toolchain binaries

building Tst with Tbt yields Tbt, and building Lst with Tbt yields
Lbt, but if you have:

Tbx - Another toolchain installation, or perhaps even
Tsx - Another toolchain source

building Tst with Tbx yields Tbc, and even building Tsx with Tbt
probably yields Tbc (although since Tsx is available a certain
amount of effort put into Tbt makes this strategy iffy).

Building Lst with either Tbx or Tbc will yield a clean /bin/login.

What if you don't trust any Tbx? Since you have Lst, it probably
doesn't take much of a source-to-source transformation (yielding
Lst') to be confident that Tbt either won't be able to identify its
binding site, or will generate obviously broken code when it tries
to insert its transposon.

Below that level, one may hope that the "semantic gap" is still
large enough that one can trust the system, but after reading some
of Andy Glew's posts in comp.arch, it seems the layerheads can get
pretty sophisticated at tracking source level phenomena.

Not much to be done about it, anyway. I may be willing to build
kernels and applications, but it's unlikely I'd tape out and fab my
own hardware. (reprogrammable gate arrays? anything interesting
been done with those recently?)

-Dave

There's a section on "bootstrapping" in the Dragon book (_Principles
of Compiler Design_, Aho & Ullman) which may make things clearer.
In my misspent youth, my work involved compiling compilers and
debugging buggy debuggers, and one of the subtler points of porting
a development system is that it does not reach a fixpoint until it
has been used to rebuild itself (including libraries, linkers, etc.)

Eugene, thanks for the clue about lyophilization; I think I can
muddle up a proper protocol. I leave it to you to work out the
implications of a Thompson-infected assembler.

Anyone know of any linux efforts towards something chroot() like for
sockets and other non-FS system calls?

Keith, should I have been able to cc: the internicity thread?