[Mono-list] bootstrapping mono with free software?

[Carl Witty]

On Tue, 2004-03-23 at 10:22, Ben Maurer wrote:
> 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.

Thanks for bringing this up.  While I don't worry about such issues
myself (I download prepackaged binaries all the time), I do enjoy
thinking about them.

> 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.

I have several options for making sure my gcc binaries match the
sources, depending on my level of paranoia: bootstrap from a commercial
compiler; bootstrap from two different commercial compilers (under
different operating systems) and make sure the results are identical;
write a C interpreter and bootstrap from that.

> 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?

Depending on how paranoid you are:

Maybe you're worried that some rogue engineer at WizzyCorp added a back
door into the WizzyCorp processor.  The back door is probably small and
subtle (or somebody would have noticed that the engineer's module takes
way too much board area, or runs too slowly).  It's unlikely to be
something like noticing the login process, and accepting a certain
password; the engineer doesn't have enough bits of storage for anything
that complex.  It's more likely to be something like: if you execute
some strange instruction sequence, then you get to execute kernel-level
code (ring 0, supervisor, whatever).  The instruction sequence has to be
sufficiently unlikely that people won't stumble across it by accident;
only people who know about it ahead of time will create it.  Then the
solution is never to execute binary code you didn't compile yourself
(since the compiler is very unlikely to create this sequence).  You
could execute untrusted code under a VM like .NET or JVM, or you could
execute untrusted machine code under an emulator like bochs or
mips64emul.

If you're worried about a more pervasive backdoor (due to a conspiracy
among several engineers, or authorized by WizzyCorp management), one
which might be capable of noticing the login process, then your options
get a lot more expensive and worse-performing.  One idea is to have two
boxes with different processors running the same software.  They
communicate to the outside world through a single link; all input from
the outside world is duplicated to both machines, and output is only
allowed back to the outside world if both machines say the same thing.

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

I doubt that a rogue engineer could insert a back door into a RAM chip;
I'll bet that every RAM design has several engineers who know exactly
how many transistors the data goes through and can explain the reason
that each transistor is required.  If you're still worried about the
RAM, then fall back to the multiple-system idea described above; or run
under a modified version of bochs, where the emulated machine's main
memory is encrypted.

> 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.

Even if mcs is easy to verify with a disassembler, that's no reason not
to verify the compilation as well.

> 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'm not convinced by this argument.  While a backdoor in a high-profile
project is more likely to be detected, it's also a more attractive
target.

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

Let me also point out that verifying that compiler sources and binaries
match up really only helps if somebody has audited the compiler sources.

Carl Witty