Compiling Rust with GCC: an update

Posted Sep 11, 2022 1:04 UTC (Sun) by mjg59 (subscriber, #23239)
In reply to: Compiling Rust with GCC: an update by himi
Parent article: Compiling Rust with GCC: an update

And it's sufficient for David A Wheeler's Double Diverse Compilation - if you build rustc with rustc and also build rustc with mrustc, and then run rebuild rustc with both of those outputs, if you get identical output then there's no backdoor (or alternatively both are backdoored, but that would mean whatever you built mrustc with is backdoored, and you can verify that through another round of DDC)

to post comments

Compiling Rust with GCC: an update

Posted Sep 12, 2022 11:54 UTC (Mon) by paulj (subscriber, #341) [Link] (5 responses)

That statement isn't true though. The risk is reduced, but not eliminated.

Compiling Rust with GCC: an update

Posted Sep 12, 2022 22:08 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (4 responses)

In what way is it not eliminated?

Compiling Rust with GCC: an update

Posted Sep 12, 2022 22:29 UTC (Mon) by paulj (subscriber, #341) [Link] (3 responses)

You're making an assumption that a subversion of a compiler binary can only be carried out by a binary of the same compiler.

There is no good reason to make this assumption. Particularly given the existence of file formats that aggregate different executable blobs together, along with hooks to allow execution to occur on loading. Even without those formats, there is simply no good reason to think the attacker who can (originally) cause a distributed binary of compiler A to be subverted must be limited to targeting the further subversion of /only/ compiler A source and binary.

Hell, even Thompson's original PoC targeted /two/ sets of sources for subversion of output.

The chances that a binary subversion targets your mrustc compiler AND your C++ compiler to compile mrustc may be lower than a subversion targeting just one, but that's kind of assuming you and your work-flow are not specially interesting to a skilled and sufficiently capable attacker. And such assumptions are not a basis to state "it is eliminated".

There are other assumptions in the DDC paper, e.g., that we could dig up some old compiler that existed before our potential-target. But then... we're still trusting a number of things, including the MAC algorithm. And MACs have a finite shelf-life - they weaken over time. Maybe the probability is low, but that depends on the juiciness of the target and the threat-model - and "lower probability" is different to "eliminated", unless you're into hand-waving.

Compiling Rust with GCC: an update

Posted Sep 13, 2022 2:37 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

No, you can generate a trusted compiler via a directly introspectable process. Pick an architecture. Write a trivial assembler directly in machine code. Use that to bootstrap a more competent assembler. Write a trivial C compiler. Use that to build an extremely old version of gcc. Use that to build a modern version of gcc. Use that to build a cross-compiler for whatever architecture you actually care about. You now have a trusted compiler, and the rest of Diverse Double Compilation falls out of that.

Compiling Rust with GCC: an update

Posted Sep 13, 2022 4:01 UTC (Tue) by pabs (subscriber, #43278) [Link]

The Bootstrappable Builds project is an example of doing just that, although they aim to bootstrap all architectures from that initial machine code step, without going through the cross-compiler stage:

https://bootstrappable.org/

Compiling Rust with GCC: an update

Posted Sep 13, 2022 9:54 UTC (Tue) by paulj (subscriber, #341) [Link]

Building your own trusted tool chain is following Thompson's advice on what you need to do to build trust. So... not DDC.

Compiling Rust with GCC: an update

Posted Sep 12, 2022 22:12 UTC (Mon) by himi (subscriber, #340) [Link] (2 responses)

I'd have to actually check the bootstrap process for rust (it's probably been five years since I last tried), but I have a feeling you have a second step beyond just building rustc with mrustc, though that may be more of a verification step. mrustc doesn't have a lot of the memory safety features of rustc, and only implements the minimal features needed to compile rustc, so I don't think a compiler built by it will behave the same as the compiler built by rustc, even if it's the same version (i.e. mrustc building rustc 1.54 compared with rustc 1.54 building rustc 1.54).

It does still break (or dilute greatly) the chain of trust, but you'd need a more careful verification to make sure nothing hinky was going on.

Compiling Rust with GCC: an update

Posted Sep 13, 2022 2:39 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

I'd expect rustc built with mrustc to behave differently in various ways (such as plausibly not being correctly memory safe in the face of malformed input), but I'd expect the actual compilation process to be the same? It doesn't really matter, though, since you can just do another round of building rustc and you should have the same assertions around it being trustworthy.

Compiling Rust with GCC: an update

Posted Sep 13, 2022 8:30 UTC (Tue) by farnz (subscriber, #17727) [Link]

Assuming mrustc is bug-free against its own spec, the rule is that it'll compile all code that rustc does with the same behaviour in the final compiled binary, but it will also compile programs that rustc rejects as invalid. For this comparison purpose, that's good enough - you can't trust an mrustc-built compiler if you don't also have a rustc-built compiler from the same source.