Allow building the initial raw toolchain without containerization

[Googulator]

I was exploring Azure Linux from a bootstrappability standpoint, specifically, building it on top of live-bootstrap without additional external binary dependencies. (Conflict-of-interest disclaimer: I'm one of live-bootstrap's developers.)

The way Azure Linux is built comes very close to achieving this, using a Linux From Scratch-based strategy for creating the initial "raw" toolchain - very similar to what was done to bootstrap Gentoo previously. Unfortunately, this is all defeated by the use of a prebuilt Azure Linux Docker image to wrap the LFS environment, creating precisely the kind of circular dependency (and potential Trusting Trust attack vector) that bootstrapping from source is meant to avoid.

As far as I explored, beyond this initial step, all further steps rely only on binaries built in the previous steps, without pulling in further precompiled binaries. Therefore, having a NO_TOOLCHAIN_CONTAINER=y option to disable containerization of the raw toolchain build would enable propagating trust from a bootstrapping environment to the Azure Linux toolchain, and eventually the whole distribution.

[Googulator]

Thought about this more, and now I would like to propose a 3rd mode as well: build raw toolchain outside any container, use it to build packaged toolchain #1, build another raw toolchain in container, use that to build packaged toolchain #2, and compare the 2 sets of packages. This would further build trust via Diverse Double Compilation - assuming that toolchain packages are reproducible, of course.

[anphel31]

Thank you for reaching out. I think that supporting a bootstrap scenario without requiring the docker container would be a very useful feature.

You are correct to point out that after using the docker container to compile the temporary tools, everything else in our toolchain is compiled from source, with no additional binary seeds. We essentially mimic the LFS process in the container, and then copy that toolchain out to be used in a chroot. We then use the chroot (which contains GCC and RPM build tooling) to build all our toolchain SPEC files.

From what I can tell, the live-bootstrap project currently only builds a 32-bit X86 toolchain. Can you confirm this? The project appears to contain at least partial support for both x86-64 and ARM64, but the python tool mentions only x86 support.

Azure Linux currently only supports 64-bit x86-64 and ARM64 architectures. I don’t think we would be able to start from live-bootstrap unless we also built a cross-toolchain to compile our 64bit packages.

[Googulator]

Live-bootstrap currently builds 32-bit binaries (including a 32-bit Linux kernel, if kernel bootstrap is enabled) - however, the final bootstrapped environment is sufficient to cross-compile and kexec into a 64-bit kernel, and then build up a 64-bit LFS userland, as was done in https://gist.github.com/Googulator/86af97ed078eb9e6c18c6eb49e46c96d#file-bare-metal-live-bootstrap-gentoo-sh-L104 (https://gist.github.com/Googulator/86af97ed078eb9e6c18c6eb49e46c96d#file-bare-metal-live-bootstrap-gentoo-sh-L467 for the 32->64-bit kernel switch) to bootstrap a 64-bit Gentoo.

This same cross toolchain should also be sufficient to get an Azure Linux build kickstarted, so long as the requirement for Docker and the associated non-bootstrapped container image can be eliminated.