[Mono-list] bootstrapping mono with free software?
Tue, 23 Mar 2004 20:32:51 +0100
tis 2004-03-23 klockan 19.22 skrev Ben Maurer:
> 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
Valid point. However, it's all about risk/feasability. Just because I
can't verfiy evertything back to the big bang doesn't mean that is's
pointless to be somewhat strict about what I do in the environment
that I have choosen to trust.
> In short, the verification of mcs is probably the least of your
> problems. There are much bigger things you would really need to
> and mcs is easy in comparison.
I disagree. Yes, mcs is "easy" to verify, but it is also a very powerful
point of entry for some black hat since the abstraction level is much
higher than say the CPU or even your average lib/c compiler.
One can never be totally secure, but an attack that propgagates a trojan
from my cc/libc by the way of the Portable.NET runtime into mcs is
several orders of magnitude more difficult to execute than the attack
that I described in my original post.
Then there is hack value, and that is of course the most important
reason for trying bootstrapping mono from Portable.NET.
> > I just tried to this, with mixed success. A trivial patch to
> > 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.
Of course. But hacknig mcs is so much easier since it's written in a
better language :) If there is ever an officially supported way of
bootstrapping mono with Portable.NET all fixes would of course be
applied on the appropriate places in the respective trees first.
> System.Reflection.Emit was never designed to compile corlib. Remember,
> csc.exe is written in C++, it uses Microsoft's internal C++ interface
> 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
> `magic' methods.
Ok. Perhaps something to do when I'm bored someday.
> 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).
True, but that would mean that I'd need to buy windows licenses that I
won't use for anything else.
> For the reasons stated above, I think this is an effort that will not
> net you any additional security.
I fail to see how you draw that conclusion. The total security is equal
to the security of the "weakest link" in the chain and you can't know
beforehand which link is weakest. Therefore improving the safeguards
against a certain class of attacks against the distributed mcs/corlib
binaries will give additional security. It might not be much though. And
then there is hack value :)
And the lions ate the christians and the christians burned the witches,
and even I am out of explanations -- Ola Salo
gpg fingerprint: F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09