RE: [Mono-list] Bootstrapping
When I looked into the mono/runtime dir, I found a bunch of windows .dll files. Just because the files are called .dll doesn't mean they are Windows libraries. I believe Mono uses the .dll and .exe extensions just to make compatibility with binaries using those names for references easier. I'd be happy to write up some docs on how to do this if they aren't currently posted somewhere, can someone help get me started? It appears that binaries are distributed with mono, but can mcs build it's own? And then you overwrite the mono provided ones? Is that what was expected? There is a script on go-mono.com that's supposed to get all the data and bootstrap/build from scratch. http://www.go-mono.com/compiling.html http://www.go-mono.com/mono-build.sh http://www.go-mono.com/mono-build-w32.sh I've been trying to use these, as a low-priority project at work, for the last week, with too little success to be happy about it. These scripts have been billed as pulling down necessary dependencies, but in reality, that hasn't really worked -- although I've followed the dependencies and pulled them separately. Then, after building, the scripts fail on some file missing from ../mcs/... -- the scripts don't even pull down mcs. I don't think they've been maintained for a while, but I've had no luck asking people on this list, and while I'm very comfortable with GNU make and GCC, I have very little automake-fu, and even less Mono-fu, so I haven't been able to figure out how these scripts are REALLY supposed to come together. I think the release of 1.0 has probably taken everyone's time, too, so this might not have been a good time to try coming into CVS building from scratch. Cheers, / h+ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Bootstrapping
So just because I sent this message, I finally got it to work, at least on Linux. I did something approximating the following: 0) install all prerequisite tools 1) get mono-build.sh 2) set CVSROOT and run cvs login 3) run mono-build.sh (this fails in the end) 4) cvs checkout mcs 5) cd mono 6) make monolite-bootstrap 7) make install I can now add install/bin to my PATH, and use mcs to compile hello world and execute it. I can take that hello world exe and move it to a Windows box, and run it using the MS .NET runtime. So far, so good! I still want to know what I'm missing WRT mono-build.sh not working right, though. Cheers, / h+ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jon Watte Sent: Sunday, July 04, 2004 9:26 AM To: Brandon Knitter; 'mono-list' Subject: RE: [Mono-list] Bootstrapping ... There is a script on go-mono.com that's supposed to get all the data and bootstrap/build from scratch. http://www.go-mono.com/compiling.html http://www.go-mono.com/mono-build.sh http://www.go-mono.com/mono-build-w32.sh ... ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Bootstrapping
I read through the docs for the CVS compile, as well as looked at the Mono Runtime source code disrtibution and the MCS source code distribution. What I found was that the mcs package requires the mono package to be compiled and installed. When I looked into the mono/runtime dir, I found a bunch of windows .dll files. So now I'm confused. Is Mono just a wrapper around some Microsoft.NET Windows .dlls? It wouldn't appear so cause the .dll files don't have the Microsoft stamp on them!?! :-/ So I guess it comes down to this: where are the bootstrap build directions? I want to build everything from scratch...i.e. I want to see the .dll files and .exe files get built on my machine. I'd be happy to write up some docs on how to do this if they aren't currently posted somewhere, can someone help get me started? It appears that binaries are distributed with mono, but can mcs build it's own? And then you overwrite the mono provided ones? Is that what was expected? I have both Linux and Windows here to build upon. So I wouldn't mind if I had to go through the work of making a build env, documenting it, and then submitting it back to the developers. Finally, is there a web based CVS viewer someplace? I can't find any links to viewcvs. Thanks, -- -bk ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Bootstrapping
The DLLs are not DLLs in the sense of binary shared libraries for Windows. The files in mono/runtime are CLI/.NET assemblies (libraries, in this case). The mono.tar.gz file contains prebuilt mcs.exe and DLLs. Once you have the prebuild versions installed, you can download mcs.tar.gz and build your own from source. You need the prebuild versions installed because the Mono C# compiler is written in C#. Without a C# compiler, you could not compile mcs. Also, note that the mono CVS module does *not* contain the prebuilt files. On Saturday 03 July 2004 5:24 pm, Brandon Knitter wrote: I read through the docs for the CVS compile, as well as looked at the Mono Runtime source code disrtibution and the MCS source code distribution. What I found was that the mcs package requires the mono package to be compiled and installed. When I looked into the mono/runtime dir, I found a bunch of windows .dll files. So now I'm confused. Is Mono just a wrapper around some Microsoft.NET Windows .dlls? It wouldn't appear so cause the .dll files don't have the Microsoft stamp on them!?! :-/ So I guess it comes down to this: where are the bootstrap build directions? I want to build everything from scratch...i.e. I want to see the .dll files and .exe files get built on my machine. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
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
Re: [Mono-list] bootstrapping mono with free software?
Noa Resare wrote: 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. How about running the newly compiled mcs.exe against PNET's corlib to compile Mono's? Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
Instead of going outside of the project, why don't we just ask to have the distribution files include a PGP signed MD5Hash? This is pretty much standard practice for many projects. rob Noa Resare wrote: Hello friends I had a look at mono again yesterday for about a year away from it, and you guys have really been productive. One thing however that I think is a bit frustrating with mono is that to bootstrap it you distribute quite a lot of binary files (in the mono/runtime directory). This is maybe convinient, but from a security standpoint it means that you need to blindly trust whoever has control over the distribution path of the binaries. (Modifying mcs.exe that makes string comparisons always succeed if compared with the magic string LawrJj4joR6c and adding code that makes mcs.exe compiled with that tainted mcs.exe do the same thing without the source code for it is left as an exercise to the reader. If such a binary was ever included in the mono distribution someone would have a magic password that worked here and there and detecting the backdoor would be non-trivial.) 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. 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. 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?) cheers /noa ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
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 verify, 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 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. 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 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. 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 :) cheers/noa -- 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 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
On Tue, 2004-03-23 at 14:24, Noa Resare wrote: 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. 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. Not really. If you can get a backdoor into the C compiler, you can make any kernel routine do anything. So, rather than just your app accepting a backdoor password, i have a nice little rootkit. Then there is hack value, and that is of course the most important reason for trying bootstrapping mono from Portable.NET. Yep, there is a hack value to this. Just dont trick yourself into thinking that you are enhancing security when you are doing a hack ;-). 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. 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. I don't think shifting around mcs source code is the correct way to fix cscc. Anyways, where is that hack value? Don't you want to make the software you are touching *less* buggy. 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. What i mean to say is: You do not have to use mcs to compile corlib, you can just use any other c# compiler. MCS is not able to compile corlib on the MS runtime, I would not expect any runtime other than Mono to bootstrap corlib with mcs. 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 :) I am pretty sure that the potential to have a rootkit inside your kernel is much greater than the risk that mcs is corrupt. And the ability to detect the former is very low, given that you would pretty much have to inspect the bytes on your disk with a `clean' computer. MCS on the other hand, you could just disassemble. Again, there is a hack value here, but the security benefit is very marginal, I argue that it does not even exist. -- Ben ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
tis 2004-03-23 klockan 20.37 skrev Ben Maurer: Not really. If you can get a backdoor into the C compiler, you can make any kernel routine do anything. So, rather than just your app accepting a backdoor password, i have a nice little rootkit. Of course having a trojan in the system c compiler has other implications, but there are also other ways of verifying the system at that level (multiple c compiler implementatations with different origin, and multiple libc-implementations for example). Self-hosting environments (such as mono and glibc/gcc) have the problem of trojans propagating in binaries without being present in the source. As soon as you can bootstrap the system from something different it makes the trojan-propagation much much more difficult (but not impossible). I don't think shifting around mcs source code is the correct way to fix cscc. My point was that while I was doing this experiment simple workarounds in mcs was much easier for me. Of course it would be better in the long run to actually fix the buggy compiler, or at least report the bugs to the proper maintainer. I am pretty sure that the potential to have a rootkit inside your kernel is much greater than the risk that mcs is corrupt. And the ability to detect the former is very low, given that you would pretty much have to inspect the bytes on your disk with a `clean' computer. On the other hand, bootstrapping gcc from sun cc on a sparc and cross compiling over a gcc to my architecture would decrease the probability that any compiler trojans mess up my kernel kernels. I am happy to hear that the same method can be used for mono with the micrsoft c# compiler. cheers/noa -- 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 ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] bootstrapping mono with free software?
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
