At 9:02 AM -0400 9/23/99, Steven M. Bellovin wrote:
>In message <v04210102b40f68d103d7@[63.193.122.223]>, Martin Minow writes:
>
> >
> > Yeah, but 370 Assembler H had a very extensive macro facility and
> > you could hide all kinds of wierd stuff in 370 code. Not too many
> > folk left around who can read it.
If I remember right you could turn off macros, but even if you could
not, it is easy to filter your assembler source to ensure there are
no macro definitions. And here are plenty of people who are still
using 370 code. I believe the entire US enroute air traffic control
system is written in BAL.
>
>And those of us who once could no longer remember how to -- for me, it's at
>least 20 years (more like 25, actually) since I touched the stuff...
> >
> > I have a copy of Decus C (Open Source PDP-11 C) lying around and
> > wrote enough of its compiler and code generator to know what it can
> > and cannot do, in case anyone is interested. The entire source code
> > of the C compiler is small enough to sight-verify in about a man-month.
> > A "Small C" compiler (see early issues of Dr. Dobbs) can be implemented
> > in about 3 man months and ought to be good enough for crypto work.
Martin, you should Zip or tar those files and sign the archive
immediately. Then publish the signature here.
>
>That isn't the real problem -- most crypto routines per se are small enough
>that one could verify the machine code without too much effort. The problem
>is the environment they're embedded in. By that I mean not just the
>crypto-using application, but the entire operating system. By example, I
>could verify the machine code for IDEA, but not PGP and certainly not your
>favorite version of UNIX.
>
> --Steve Bellovin
The point of having a verified small C Compiler is not to compile
crypto code, it is to compile GNU C++ or an intermediate-sized
open-source compiler that can then compile GNU C++. The goal should
be to produce a signed golden object version of GNU C++ whose
provenance, in terms of the object code that was used in compiling
it, is reproducibly traceable to either an ancient compiler or a
small compiler that any computer science class can build from scratch
as a term project -- preferably both.
Our moderator, whose hard work in keeping this list excellent I
really appreciate, but with whom I must disagree here, interjected:
>[And then how do you trust your assembler? Or the compiler and
>assembler you compiled the C compiler on? And the linker? If you
>really try hard enough on all this, you find your self smack dab in
>front of Kurt Goedel's door, and he tends to have unpleasant news for
>visitors who come to him looking for solace.
> --Perry]
Perry, if you really believe that the question of whether a given
lump of object code contains a Thompson Trap is formally undecidable
I'd be interested in seeing a proof. Otherwise Herr Goedel has
nothing to do with this. Your argument reminds me of claims I always
hear that nothing can be measured because of the Heisenberg
Uncertainty principle. I don't dispute that building trusted systems
is hard and time consuming or that Thompson's paper adds another
dimension to the difficulty, but his work does not prove it is
impossible.
On the other hand, you did mention me in the same breath as David
Hilbert, so perhaps I shouldn't complain.
Arnold Reinhold
