A lot of this bootstrapping stuff comes back to the ‘trusting trust’ attack. You could write a compiler that adds some malicious code to programs it compiles. But the thing is, it could also insert it’s own malicious code when compiling a compiler. So you look at your code, and the code of your compiler, and everything looks fine, but the exploit is still there. Someone wrote an example in rust.
Theoretically there could also be bugs that propagate this way. So to fully trust your code is doing what you think it is, you’d need a chain of compilers back to hand coded assembly.
Why would a Rust compiler written in C be more trustworthy than one written in Rust?
If the idea is that, in an ideal world, we would compile each layer of compilers from assembly-up-to-Rust for each build, that seems even more risky as then you have to trust each compiler instead of just one.
That’s already how it is now, we just don’t usually think of it that way. You can’t compile rust unless you already have a rust compiler. The current version was compiled in a previous version, which was compiled in a previous version, going through a chain of older versions and other languages. Anything along that chain could’ve theoretically had an influence on the current compiler.
It’s not about the code itself being more trustworthy. The point is that when you bootstrap, you don’t have to blindly trust any of the binaries, since it’s source code the whole way down. Someone could bootstrap rustc like this, compare it to the binaries that already exist, and ideally they would be identical.
Oh, okay. Thank you for clarifying. So doesn’t that mean we should never have a compiler written in the same language that it compiles? Why would we ever choose to make the mistake of using the same language? Is it ever not a mistake?
It makes sense that if you’re designing a language, you’d like the language you made and would want to use it. It’s fine for compilers like that to exist, and even be the main one used, but ideally it shouldn’t be the only compiler.
But there are technically ways to bootstrap a language without writing it in another language (other than a small core in assembly or something). You could design a tiny compiler that only handles a small subset of your language, then write a better compiler using only the features available in that subset. You can do this for several layers of compilers until you have the full language.
I’m still lost on why they’re doing it.
A lot of this bootstrapping stuff comes back to the ‘trusting trust’ attack. You could write a compiler that adds some malicious code to programs it compiles. But the thing is, it could also insert it’s own malicious code when compiling a compiler. So you look at your code, and the code of your compiler, and everything looks fine, but the exploit is still there. Someone wrote an example in rust.
Theoretically there could also be bugs that propagate this way. So to fully trust your code is doing what you think it is, you’d need a chain of compilers back to hand coded assembly.
Why would a Rust compiler written in C be more trustworthy than one written in Rust?
If the idea is that, in an ideal world, we would compile each layer of compilers from assembly-up-to-Rust for each build, that seems even more risky as then you have to trust each compiler instead of just one.
That’s already how it is now, we just don’t usually think of it that way. You can’t compile rust unless you already have a rust compiler. The current version was compiled in a previous version, which was compiled in a previous version, going through a chain of older versions and other languages. Anything along that chain could’ve theoretically had an influence on the current compiler.
It’s not about the code itself being more trustworthy. The point is that when you bootstrap, you don’t have to blindly trust any of the binaries, since it’s source code the whole way down. Someone could bootstrap rustc like this, compare it to the binaries that already exist, and ideally they would be identical.
Oh, okay. Thank you for clarifying. So doesn’t that mean we should never have a compiler written in the same language that it compiles? Why would we ever choose to make the mistake of using the same language? Is it ever not a mistake?
It makes sense that if you’re designing a language, you’d like the language you made and would want to use it. It’s fine for compilers like that to exist, and even be the main one used, but ideally it shouldn’t be the only compiler.
But there are technically ways to bootstrap a language without writing it in another language (other than a small core in assembly or something). You could design a tiny compiler that only handles a small subset of your language, then write a better compiler using only the features available in that subset. You can do this for several layers of compilers until you have the full language.