Possible to build rust without using blobs at all?

Hello all!

I'd like to build rust fully from source without using an intermediate binary blobs built by anyone else and downloaded from somewhere.

Is it possible nowadays? Is there an instruction how to do that? The official instruction assume using standard ./configure which uses the elf binaries from static.rust-lang.org :frowning:

1 Like

You would have to go back to the days when Rust was implemented in OCaml, and hen compile forward from there. It's roughly 900 builds. Good luck. :slight_smile:

(Oh, and then, you'd have to build your own OCaml compiler. It's written in C. So you'd need to write your own C compiler...)

4 Likes

C compiler is not a problem. I'm not aware of a system that has not a C compiler :slight_smile:
But 900 builds is really sad.

Well, you said no binary blobs. It's worth thinking about why you're okay with a C binary blob, but not a Rust one.

7 Likes

I'm not aware of a system that has not a C compiler

If you want to do this to obtain a compiler that targets (or runs on) an arbitrary platform, Rust supports cross compilation out of the box (just set the host and target platforms with configure and get the right toolchain). More obscure platforms may need you to modify libc.

Surely, the gist of this post is about trusting the bootstrap compiler.

1 Like

That did seem to be the gist of this post before the comment that Manishearth particularly replied to. But that comment implies that @fourtyseven is interested in cross compiling, and not concerned about trust.

If this is about trust, "Reflections on Trusting Trust" is a great speech, but I think its misconstrued in a lot of discussion about it as raising a security threat that we ought to protect ourselves from.

First, Ken Thompson's trojan identified the source code of the particular program he was attacking, as well as the compiler, both already available to him - inserting a general trojan that could attack some arbitrary set of programs, including the programs you care about, is a much more challenging problem. There's a quote I can't find the source of about the idea of a trojan in the OCaml compiler which inserts vulnerabilities into a program written in Rust - we should hope this vulnerability exists, because it would be definitive proof of time travel.

Second, Ken Thompson's point was that we can't guarantee the security of our systems unless we have a complete binary understanding of every program which we execute on them, something that has been impossible for a very long time. He meant that no matter what we do, we have to put our trust in someone else's code.

2 Likes

Small correction. OCaml compiler is written in OCaml. OCaml can be compiled either to native code or to byte code for ocamlrun interpreter (which is written in C). They bootstrap compiler from ocamlrun and a compiler compiled to bytecode.

He came a-cross as wanting to trust one of the existing C compilers.

Even so, the task of first inspecting the imaginary C-version of the bootstrap compiler and then the compiled rustc source seems too huge for any single person or organization.

Trust or bust!

Here's a thought: would there be value in a "bootstrap-friendly" Rust interpreter in something more broadly supported (like C) that omits all the correctness analysis, and just assumes the code its given is correct?

I'm not sure how much implementation effort that would save, but if it's significant enough, it might be worth it to get people to stop complaining about this. :stuck_out_tongue:

2 Likes

[quote="withoutboats, post:8, topic:4797"]
If this is about trust, "Reflections on Trusting Trust" is a great speech
[/quote]Thanks for the information. I will read/watch the speech as soon as I have free time.

The gist of the question is 50% about trust and 50% about a possibility to port/build rust compiler for the OS/architecture it doesn't currently support so all of you are right.

[quote="steveklabnik, post:5, topic:4797"]
why you're okay with a C binary blob, but not a Rust one.
[/quote]If I run some operating system on some hardware then I surely have a C compiler that can create executables for the system.

From portability point of view I always have C compiler on my system whatever system I run. But I have to download rust compiler from rust developers (rust-lang.org) who may never heard of the system I use. In such a case I can do nothing to get rust compiler working om my system. Though it still seems to be possible since @Manishearth pointed that rust compiler can cross compile itself for another platform.

Next, there are people (or vendor company) that provided me the software/hardware and they also provide me a C compiler. From the trust point of view they have no reason to place untrusted code in the compiler since they can place it anywhere in the system even in hardware. So I can trust them in some degree. While I cannot trust rust developers as rust compiler is the only place how they can "attack" my system. The vendor company could provide me rust compiler as well but for the time being there are only two languages that are guaranteed to be present on any system: assembler and C. If rust was in this list the question wouldn't come up.

These are the thoughts that lead me to the question. For me the OCaml way, as described by @matklad , is the best approach. If I have an older OCaml compiler I can build a newer one. If I only have a C compiler I can bootstrap OCaml one without relying on someone's else prebuilt binaries.

Also see this thread: https://www.reddit.com/r/rust/comments/3vxgp7/bootstrapping_trust_in_compilers/

Right, this is what I'm getting at: "without binary blobs" can mean a few different things. Everyone else already covered those cases above in the thread though; they need different solutions, as they're different problems.

Thanks! I had seen somewhere that it was in both, and GitHub says it's 15% C, so oops!

How is ~900 determined?

Roughly three hundred snapshots, stage 0, 1, and 2: 900

2 Likes