Bootstrappability should be a must

[luke-jr]

Until it's possible to bootstrap a Rust compiler without ANY third-party binaries, Rust shouldn't be used in something as essential as Linux.

Today, it doesn't seem possible (mrustc apparently only works on backdoored x86 platforms). If possible, it is certainly unreasonably difficult.

[memoryruins]

Are the ideas applicable to rustc's own bootstrap, and are the appropriate issues open upstream?

[Soveu]

Clang also relies on LLVM, so why should Rust be different?

[bjorn3]

LLVM and GCC can bootstrap each other using relatively old versions of the other as far as I know. Older versions of GCC can be bootstrapped using a small C compiler like tinyc in just a few steps. Rustc can only be bootstrapped using the previous version of rustc, requiring each step in between the rustc version used for bootstrapping and the rustc you want to compiled.

Mrustc recently got support for bootstrapping rust 1.39.0 reducing the amount of steps necessary for bootstrapping: https://old.reddit.com/r/rust/comments/mjxbaz/mrustc_upgrade_rustc_1390/ There is also the gccrs project aiming to make a rust frontend for GCC.

[calimeroteknik]

Can we have some reasons from the 8 people who think that bootstrappability is dispensable?
For now I can only imagine "no time for this", or the equivalent but more extensive "the benefits of added safety outweigh the loss of trustability and reproducibility". Help me out?

I stand with those who think that a solid foundation is indispensable, and that further compromission of the Linux kernel will only accelerate its growing crashiness.

[Soveu]

I don't understand what bootstrappability has to with trust and reproducibility.
Stage 2 compiler is always the same, no matter if stage 1 was compiled with mrustc or rustc.

C is an old and simple language, that is not changing very much.
Rust is pretty complex - lifetimes, trait bounds, moving values instead of copying them, enums, modules, good error messages
I bet it's possible to compile modern C programs with just a C11 compiler.
For comparison, Rust was barely a thing 10 years ago and introduced a lot of breaking changes with 2015 edition.
Even now compiler and std use a lot of experimental/unfinished features, like negative impls, specialization, box syntax.

I'm happy that we have something like mrustc, but for some (maybe long) time it will be just a rustc bootstrapper, not a fully-fledged Rust compiler

[calimeroteknik]

I don't understand what bootstrappability has to with trust and reproducibility.

The most basic argument to reply with here is Thompson's turing award lecture "Trusting trust".

Here's a PoC of it on rustc (although it works on any compiler, as it's a theoretical attack):
https://manishearth.github.io/blog/2016/12/02/reflections-on-rusting-trust/

P.S. I believe the discussion you're starting about features, complexity and instability should also happen. (in another thread)

[nbdd0121]

I give a thumb down because I don't agree with "mrustc apparently only works on backdoored x86 platforms". Making claim about the entire x86 ISA is crazy to me.

First, x86 is not a specific implementation. There are many companies producing x86 chips (Intel, AMD, VIA, etc) for ages. You can certainly get a chip without Intel ME or AMD PSP and use that. If you cannot trust any of these companies, you certainly cannot trust ARM or MIPS, and all cannot even trust on open source CPU because you can make claims like EDA tools or FPGAs are controlled by an untrusted company.

Secondly, even if we assume that there is a trustworthy platform and it is not x86, you can still use GCC to cross-compile mrustc to x86, and use QEMU to run it. Saying mrustc is not worthy because it only supports x86 is just nonsense.

So yeah, I vote down because you CAN bootstrap rust compiler without any binary. The bootstrapping chain is certainly long and it took a while from mrustc to the latest rustc, but it is not difficult. There are distributions that are already bootstrapping rustc without pre-built binary.

[calimeroteknik]

nbdd0121, thanks for specifying!

Indeed I do not know of backdoors in the x86_64 ISA itself as of yet, although I do know of backdoors in many of the faster real-world implementations of that ISA. And to be complete, I do not know of any proof of absence of any backdoor in either the x86_64 ISA, or in any real-world implementation of it. Ignorance is just ignorance, it is not reassurance in itself. (if we're going down that rabbit hole: irrefutable statements cannot be disproven any more than they can be proven, so we're back to square one)

However, the present issue is not possibility but feasibility/tractability:

If possible, it is certainly unreasonably difficult.

The people in support of this issue believe it's a major concern that the bootstrap will:

1. be using a prohibitive/discouraging amount of CPU time
2. (as a result of point 1) possibly disappear at some point, as it is an externally-maintained endeavour that could face ever-increasing difficulty
3. be tied to a single processor architecture for which we do not have fast enough real-world CPUs that also do not have broken security (it's the combination of these two that drives the point home)

In summary: the motivation of opening this issue is to ask for a high guarantee level that bootstrapping will not only be theoretically possible, but also feasible by individuals in the real world without prohibitive requirements.

And if I had to set a bound on the goal here, although I'm not a fan of comparisons, the process complexity and required computational resources of the bootstrap of Rust should remain in the order of magnitude of that of the bootstrap of a C (or, fine, a C++) compiler.
Something significantly faster than this would be the actual goal though.

[nbdd0121]

Once you get a version of rustc, you are not tied to a specific ISA. You can do cross-compilation after that.

While I agree that a easier bootstrapping path is desirable, I don't see it as a must and certainly it shouldn't block progress of using Rust in projects like Linux. Memory bugs are a more imminent threat in my opinion.

And it is not like people aren't trying to make bootstrapping easier. Projects like mrustc and gcc-rs can certainly help in this direction. If someone is particular concerning about bootstrapping time they can help to improve mrustc so it supports a newer Rust version or a different ISA.

[Soveu]

Once you get a version of rustc, you are not tied to a specific ISA. You can do cross-compilation after that.

Not really, you still need to compile LLVM
Or can you already bootstrap with cranelift?

[luke-jr]

If someone is particular concerning about bootstrapping time they can help to improve mrustc so it supports a newer Rust version or a different ISA.

I attempted to do so almost a year ago, failed to get a usable rustc, and my partial improvements went ignored by mrustc's maintainer.

[bjorn3]

Not really, you still need to compile LLVM
Or can you already bootstrap with cranelift?

Compiling a working rustc that can bootstrap itself using rustc_codegen_cranelift is possible (I have a CI job for this), but is awfully slow due to a lack of optimizations, I am not sure the cg_clif version matching the latest rustc version supported by mrustc can bootstrap rustc and only x86_64 is supported at the moment.

Cross-compiling LLVM shouldn't be much harder than cross-compiling arbitrary programs using rustc I think as rustc needs a compiler toolchain for the target anyway to provide a linker. Once you have the compiler toolchain for the target (linker and C++ compiler) the build system of rustc automatically builds LLVM for the target unless you explicitly point it to an existing LLVM installation.

[ojeda]

Closing since it is not a technical issue (please use the mailing list for discussions like this).