Re: Adding Rust and Go to the coreboot toolchain

Hi Martin,

sorry in advance if I'll ask stupid questions :)
It doesn't feel like I understood what is on your mind.

On 03.11.23 00:18, Martin Roth via coreboot wrote:
> I'm proposing that we look at adding Go and Rust to the coreboot toolchain.

What's "the coreboot toolchain" in this context?

Later you mentioned xgcc, that's the cross toolchain we use to build
coreboot itself, not its tools. Hence my confusion, do you expect Go
and Rust in coreboot itself, like Linux does? (I would welcome the
latter. But trying to see things realistic, that would require a much
bigger effort and discussions much beyond the toolchain. Also, depen-
ding on how we would use Rust, that may change requirements of the
toolchain.)

> Go:
> We’re already using a number of things written in Go as a part of the build,

Well, some builds, but not "the build". And I think we should discuss
this separately before we make it an official requirement.

> and they currently use the system toolchain, leaving droppings outside of the coreboot and $obj folders as a part of the build.

That sounds like something to tune in the Makefiles. And if not
possible yet, maybe we should help the Go developers to make it
possible.

> Additionally, we want the binary we produce to be reproducible - I’m not sure if that’s currently a problem or not. SBOM, STM

Now I'm lost. I thought we only use it to build tools. If the
output of the tools would change because of the toolchain used
to build them, wouldn't that be a real bug (either in the tool
or toolchain) and not just a reproducibility issue?

>
> Rust:
> Rust is starting to be used more and more widely as a system programming language. The Linux kernel is accepting Rust. Oxide’s entire codebase is in Rust. The Oreboot project is using Rust. While I’m not personally a fan of Rust, I can see the need to support it coming.
> Ron has already posted a patch to add Rust support, but I think it needs to be reworked so that everything is contained in the XGCC directory, has a stable version for coreboot, and doesn't conflict with any system tools.
> https://review.coreboot.org/c/coreboot/+/74124

Did try that patch now and it raises a lot of questions. EDIT: now
that I went through everything below, I think the most important
question is
  Would we want to use `rustup`?

It started somewhat like this:

  rustup run --install 1.67 cargo install --version 0.3.4 cargo-binutils
  make: rustup: No such file or directory

Trying to install `rustup`:

  :: rustup and rust are in conflict. Remove rust? [y/N]

So to use this, I have to kill my local Rust toolchain?

Then, `rustup` ran for a while, told me what it downloaded and compiled.
And I thought, nice, it's compiling from source. But isn't the Rust com-
piler written in Rust? didn't I just delete my Rust compiler? I suppose
the toolchain was downloaded as binary.

Then it went on with the next `rustup` command. Looked about the same,
but what? aren't these the same packages it's compiling? Looking at the
running processes, they were. But to my surprise nothing changed in my
.cargo directory. Could still be that something was statically linked
and the artifacts removed. But it seems like an inefficient way to use
software anyway. IMO ok for somebody typing these commands into a
terminal, but a bit too much to put into a script for anybody to use
without additional thought.

This story reminded me of two things:

 1. Currently we have a chain of trust:
    * our Git repository and the checked out commit (hash)
    * hashes for files to download (e.g. for the GCC sources)
      - those are checked into the repository
    If we surrender the control about what to download (and install
    and run) to another program, we should probably warn the user.
    I had a quick look at `rustup` and `cargo` and couldn't find an
    answer if things can be specified by hash. I hope they can.

 2. So far we built everything (that was added on top of the user's
    OS distribution) from source. I think we should be proud of that.

> Neither of these is particularly urgent in my opinion, but I want to get the discussion started. I've added this as a topic to the next coreboot leadership meeting.

I would just wait until somebody committed to maintaining coreboot
needs it and then assist them the best we can to add support.

Nico

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]