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