Portable and reproducible kernel builds with TuxMake

Posted Jan 6, 2021 2:36 UTC (Wed) by darwi (subscriber, #131202)
Parent article: Portable and reproducible kernel builds with TuxMake

> In the case of reporting a build problem to a mailing list, a one-line TuxMake command communicates precise instructions for reproducing the build problem. Any user who runs the same TuxMake command against the same Linux source tree will see the same build.

In the examples shown, the printed tuxmake command "to reproduce this build locally" does not show the GCC version. How do you plan to handle future GCC versions?

It would also be nice if there is a way to extract all the pure build parameters and defconfig in a simple file, so that bug reporters can send *that data* instead of a "tuxmake command". Kernel developers / maintainers on the receiving end should not be forced to use "tuxmake" to reproduce bug reports.

(I'm honestly not a fan. At least on Debian, all the needed toolchains are one "apt-get gcc-${ARCH}-linux-gnu" away. But I understand the possible need for CI).

Portable and reproducible kernel builds with TuxMake

Posted Jan 6, 2021 9:15 UTC (Wed) by amacater (subscriber, #790) [Link] (2 responses)

Antonio is a Debian developer: this has direct relevance to making Debian reproducible builds, for example.. It's a worthy step forward for its use cases.

Portable and reproducible kernel builds with TuxMake

Posted Jan 6, 2021 9:42 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

Debian's builds, strictly-reproducible or not, already create a .buildinfo artefact that lists the versions of all tools used to effect the build. Thus there's no need for yet another, container-based (ugh), tool like TuxMake that only works for a single package (the kernel).

Reproducible kernels are a very good idea, but they need to be based on reproducibly-built tools. Otherwise you have containers with SHA256s which you base your build on all you want, but what assurance do you have that the container was built with non-compromised tools in the first place? Does TuxMake address this?

Portable and reproducible kernel builds with TuxMake

Posted Jan 6, 2021 17:15 UTC (Wed) by terceiro (subscriber, #83820) [Link]

> Reproducible kernels are a very good idea, but they need to be based on reproducibly-built tools. Otherwise you have containers with SHA256s which you base your build on all you want, but what assurance do you have that the container was built with non-compromised tools in the first place? Does TuxMake address this?

The TuxMake container images are built upon the Debian images provided by Docker Inc. They use only official Debian packages, with the exception of daily toolchain builds for which we get packages from the upstream project. They are built on Gitlab CI, with arm64 builds done by a Linaro server, and x86_64 done by Gitlab.com workers. Therefore at the moment the integrity of the TuxMake images relies on the integrity of Docker Hub, Debian, LLVM nightly builds, Gitlab.com, and a Linaro server.

Given the current state of reproducible builds in the free software community, would say the TuxMake containers are just good enough to get started. Of course, we can and should improve upon that (both TuxMake and the rest of the community). On the other hand, except for that Linaro server, a compromise in any of those means we all have bigger problems than the non-reproducibility of the TuxMake container images.

Portable and reproducible kernel builds with TuxMake

Posted Jan 6, 2021 15:07 UTC (Wed) by mndrue (guest, #115498) [Link] (1 responses)

> Kernel developers / maintainers on the receiving end should not be forced to use "tuxmake" to reproduce bug reports.

We agree. Currently, most build reports from users on lkml look something like "My build broke with the following error". If the recipient is lucky, the author mentions a config, toolchain, or architecture. Usually, in the case of a tricky build problem, it's a few round trips to figure out how to reproduce the build error reported.

The tuxmake reproducer already gives more information to the recipient, whether or not they choose to use tuxmake, than most build reports. It's designed to be self describing. From the article:

> tuxmake -r podman -a arm64 -t clang-11 -k defconfig -K CONFIG_KASAN=y -w ccache

I'm hopeful that even that short version of the command communicates enough information to reproduce a build problem, with or without tuxmake.

We've tried to make tuxmake as stupid as possible, so that it's not doing any clever things that a kernel developer wouldn't expect.

Portable and reproducible kernel builds with TuxMake

Posted Jan 6, 2021 18:40 UTC (Wed) by darwi (subscriber, #131202) [Link]

> It's designed to be self describing. From the article: "tuxmake -r podman -a arm64 -t clang-11 -k defconfig -K CONFIG_KASAN=y -w ccache".

Yes. What grabbed my attention though was the GCC case, where (unlike clang) the version was not explicitly stated in the "tuxmake reproducer" line :)

> We've tried to make tuxmake as stupid as possible, so that it's not doing any clever things that a kernel developer wouldn't expect.

I see. Thanks for the clarification (and for popularizing podman!).

Portable and reproducible kernel builds with TuxMake

Posted Jan 6, 2021 15:40 UTC (Wed) by terceiro (subscriber, #83820) [Link]

> In the examples shown, the printed tuxmake command "to reproduce this build locally" does not show the GCC version. How do you plan to handle future GCC versions?

When using containers, you can request a (major) compiler version explicitly, and that's what you will get. Otherwise, all that TuxMake can do is use whatever gcc you have on $PATH. In any case the exact compiler version that was used is recorded in a metadata file which is collected from the build environment.

> It would also be nice if there is a way to extract all the pure build parameters and defconfig in a simple file, so that bug reporters can send *that data* instead of a "tuxmake command". Kernel developers / maintainers on the receiving end should not be forced to use "tuxmake" to reproduce bug reports.

Beyond tool versions, the metadata file also contains info about the input tree and build output, plus all the inputs that have been provided by the user such as toolchain, target architecture, config arguments etc. The final kernel config is also included in the build artifacts.