In comp.os.linux.advocacy, Oliver Wong
<owong RemoveThis @castortech.com>
wrote
on Mon, 25 Sep 2006 18:42:29 GMT
<pqVRg.32844$bf5.2599@edtnps90>:
>
> "The Ghost In The Machine" <ewill RemoveThis @sirius.tg00suus7038.net> wrote in message
> news:tnalu3-o6c.ln1@sirius.tg00suus7038.net...
>> In comp.os.linux.advocacy, Lawrence D'Oliveiro
>> <ldo RemoveThis @geek-central.gen.new_zealand>
>> wrote
>> on Sat, 23 Sep 2006 16:44:41 +1200
>> <ef2e1v$ll6$7@lust.ihug.co.nz>:
>
>>> You don't have to trust us, or anybody else. Because you can look at the
>>> source code to check it for yourself.
>>
>> If one knows how to read it. 
Fortunately, that's
>> a fair bit easier, even for one schooled in English and
>> math but otherwise not literate in C or C++, than trying
>> to disassemble machine language.
>>
>> There are a lot of issues here, though, and suggesting
>> that one read the source code is a bit on the glib side,
>> especially since compiler hacks to miscompile that code
>> have been around since Unix.
>>
>> Fortunately, the source code for gcc is available as well,
>> if one knows how to read *it* (byacc is a little obscure
>> but usable enough for neophytes, and LALR experts can make
>> it do all sorts of things ).
>
> When presented with source code and a binary, you can't ever be 100%
> sure that the source code presented is the one used to create that binary.
> Of course, you could just discard the binary and recompile yourself to be
> sure that the source code and the binaries match.
>
> But what do you do if the binary you're trying to verify is the compiler
> itself?
>
> - Oliver
>
A project I for one am still researching. Briefly put,
given a blank computer (no BIOS, no OS on disk, no
nothing), how does one ensure that each and every stitch
of code goes through a proper verification process as one
sets it up?
The best I can do requires some mildly interesting
equipment. The context, in this case, would be a
lead-copper shielded laboratory or work area -- in other
words, no mind-control beams, radioactivity, etc. except
as directed by the worker(s) therein. Of course most people
won't have quite this level but even one's own bedroom,
basement, or kitchen would probably suffice for most
applications, assuming the Russians aren't wandering
around the area with a small otherwise unadorned white
truck or big black limo festooned with antennae and what
appears to be a 1930's-era ray gun.
(Of course most people won't have a blank computer, either;
the BIOS is already there.)
[1] An EEPROM burner. This little device simply takes
a RAM image and burns it into a EEPROM. There should be
methods to erase the EEPROM (a UV lamp, if nothing else)
and maybe a method by which one can key in arbitrary bytes
into RAM, and display the RAM.
[2] Lots of paper, for notes and such.
[3] A fair amount of time.
[4] A seed compiler/assembler. The one that comes to
mind is a variant of SmallC; it needs to be large enough
to compile the GNU CC source. It also needs to be small
enough so that one can "compile" it (translate it into
machine code) and then key it into memory manually.
[5] A trusted storage device, such as an unaltered disk.
Vetting the disk is an interesting subproblem in itself,
but one might use an older model that doesn't use
sophisticated electronic caching. Admittedly, current
disks are idiots when it comes to data interpretation
-- but who knows what DRM will require in the future?
Perhaps the disks of the future will have to know whether
one has legitimately acquired that Whitney Houston video,
ABBA song audio, or old Howdy Doody footage.
Perhaps not.
[6] A disk exerciser/writer. This would be little more
than a RAM scratchpad and a control system for writing an
arbitrary sector of the disk. Dolphins [*] used to be used
for very old model disks in the 1980's but I have no idea
what's in the field now.
[7] Lots of specifications -- e.g., processor, address
decoding, various issues with support chips. The x86
PC is a little complicated, actually, with stuff such
as A20, INT2-INT9 chaining, and DMA0 hardwired into
the refresh circuitry.
The procedure is reasonably simple, of course.
[1] Code up the BIOS and burn it onto the EEPROM.
[2] Plug the chip in, and code up the boot sector on the disk.
[3] "Compile" the seed, and put that on the disk as well
under a proto-filesystem, along with a simple proto-shell
and whatever libraries are required. This proto-shell
just needs to invoke the compiler, and, time permitting,
manage the proto-filesystem. Code for that will probably
be in the proto-library referenced by the seed compiler;
we've not gotten to the point of a true kernel yet.
[4] Get the source code for gcc from a trusted area, and
copy that into the proto-filesystem, after manual vetting.
[5] You're now ready for compilation of gcc. The results
will be in your proto-filesystem.
[6] At this point you'll want a few other things, such
as glibc, the kernel source, utilities such as mv, cp,
etc., a bootloader, and whatever else one's heart desires,
security, time, and Russian antennae-festooned vehicles
permitting.
Now at this point you're probably asking "dude, where's
your tinfoil hat and authorization pass?" (no, I don't
work for the Feds) but it's clear that there are a fair
number of issues here, not the least of which is the list
of equipment one can trust. No doubt someone in the CIA,
FBI, or an ex-KGB agent can easily lay hands on any of the
above equipment. Note that a trusted PC can take the place
of [1] and [6]; cross-compilers on such a PC can also be
used to shave time off of [4]. But that trusted PC had
better not be on the Internet, if one can help it.
Especially if it's running a certain OS offered by a
company in Redmond.
I can tell you that the way gcc is built precludes a lot
of hacks.
[A] One is assumed to have a native compiler and library,
and the source code to gcc and maybe glibc. For Linux,
things get mildly interesting -- "chicken and egg", as
you put it -- but cross-compilation with gcc is also
possible, and indeed reasonably simple to do.
[B] cc compiles gcc, creating an executable xgcc1.
Some checking is then done.
[C] xgcc1 compiles gcc again, creating another executable xgcc2.
Some more checking is done.
[D] If necessary, xgcc2 compiles gcc yet again, creating xgcc3.
All optimizations are now in place.
Now, one might do some creative hacking -- it's been done for
various C compilers, looking for code sequences commonly used
in such places as /bin/login. It would take some doing nowadays.
BTW, specs for a tinfoil hat (more precisely, aluminum
foil deflector beanie) are available at
http://zapatopi.net/afdb/
if one needs such, and of course one can always visit the
CIA's web site for instructions:
https://www.cia.gov/
but you didn't hear it from me.
No, I can't be more
precise regarding the instructions, although the Factbook
has some interesting tidbits regarding countries.
As for vans with antennae --
the best I can do on short notice is
http://www.esa.int/esaCP/ESANKIZPD4D_index_1.html, which
is designed more for chasing interference for an ESA
space probe than detecting emanations from CIA or ex-KGB
agents.
But that white thing on top is fairly conspicuous.
(An alternate method would be to get one's hand on a CD burner
with a large scratchpad RAM buffer, and key appropriate code
into that. There would be a lot of code, though, and the
image might as well be built on a trusted machine anyway.)
[*] A brand name, of course. I highly doubt Flipper would
want to get involved here, even if Timmy did fall into
the well -- oh, wait, that's Lassie.
--
#191, ewill3 RemoveThis @earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.
)
Linux