[Mono-list] bootstrapping mono with free software?

[Ben Maurer]

fdOn Tue, 2004-03-23 at 12:34, Noa Resare wrote: 
> A solution to this problem would be to have the ability to bootstrap the
> mono environment from a verifiable source. I immediately come to think
> about Portable.NET, since the cscc compiler is written in c and the
> system bootstraps from a standard c environment without any binary code.
How did you get gcc on your system? Did you compile it from source? With
what, another gcc compiler? How did you get that gcc compiler? Did it
come with your operating system? I am betting that somewhere along the
line, you got a gcc compiler from somebody else.

Ok, so lets assume you did not, there is probably enough documentation
on how people went from punch card computers to gcc that you would be
able to replicate the steps and verify your results.

What kind of cpu are you running? Intel? AMD? Did you make the chip
yourself, where you there to see it made? Have you inspected it for a
backdoor?

How about your RAM? Did you see it being made? Is it possible that there
is some back door hidden in there?

I doubt there is one person in the world who can say that he has traced
the creation of his computer environment from square one and is the only
person who was involved in creating his computer system, from the mining
of the metal (I am sure that there is a way to make the metal corrupt or
invalid so that it is a backdoor) to the creation of the CPU to the
writing of the compiler. The creation of today's technology has taken a
very long time, it is more man-years than one person's lifetime -- by
far.

Compared to something like, say a CPU, the mcs/corlib binary that you
get is pretty inspectable. A dedicated person could probably
hand-inspect the output of monodis/ildasm/whatever pnet has in a
reasonable amount of time. Monodis is written 100% in C, so that meets
your trust requirements. The other two implementations could serve as
verification that monodis does not have a backdoor.

In short, the verification of mcs is probably the least of your
problems. There are much bigger things you would really need to verify,
and mcs is easy in comparison.

Or, in essence `We all need somebody to lean on'. Be it the distributor
of your operating system, Intel, AMD, whoever makes your ram (Who does
make ram?), you are going to be relying on something.

So, what makes distributing binaries secure? There are a few factors
that help out:

      * Who is in charge of the creation process -- the monocharge
        tarballs are cooked up inside Novell. This gives you alot of
        security. If there were to be a backdoor inside the tarball, you
        would have a clear target for blame. This is different than,
        say, some random project on SourceForge where there is no clear
        path back to the origionator of the binaries. Somebody cant do a
        `hit and run'
      * How wide of distribution there is -- There are many people using
        monocharge binaries. That means that there are more people that
        could notice if there was a backdoor. Real life example: if you
        are going to murder somebody, where would you do it, in a dark
        alley or in the middle of a busy street with cars and people. Am
        betting the first, because fewer people to observe the crime. In
        the same way, if many people use monocharge, inserting a
        backdoor has a high risk of getting caught


> I just tried to this, with mixed success. A trivial patch to mcs/decl.cs
> to work around a bug in enum initialization in cscc made mcs.exe
> compile. Some more kluges applied to to the mcs sources made mcs.exe
> work in the Portable.NET environment for simple test cases, like
> compiling a runnable HelloWorld.exe.
The correct way to go about this is to fix up cscc. MCS's source is
valid, it can be compiled with csc. 

> Trying to compile mono's mscorlib.dll however is a completely different
> experience. Exceptions from
> Mono.CSharp.RootContext.BootCorlib_PopulateCoreTypes decendands all over
> the place.
> 
> So I was hoping that someone with deeper understanding than me of the
> mono internals could do an estimation on how much work it would need to
> get mono's corlib to compile with mcs.exe executed from the Portable.NET
> runtime.
> 
> These are the non-trivial stuff that fails right now:
> 
> error CS0518: The predefined type `System.Char*' is not defined or
> imported
> 
> the same goes for 'System.Void*'
> 
> Method SetCorlibTypeBuilders is missing from
> System.Reflection.Emit.AssemblyBuilder (btw, isn't there a better way to
> do this than adding non-standard methods to the corlib?)

System.Reflection.Emit was never designed to compile corlib. Remember,
csc.exe is written in C++, it uses Microsoft's internal C++ interface to
metadata. To enable mcs to be written in c#, extensions were needed.

So, if you really want to do this, you would need to replicate the Mono
`magic' methods.

Also, you can just compile our corlib with cscc, (that is how it was
created in the first place, mcs and corlib were compiled with csc, and
scp'd over to linux).

For the reasons stated above, I think this is an effort that will not
net you any additional security.

-- Ben