From d0bb7ed61ed9e356c53de1a8e9bd6c2ec030ffb6 Mon Sep 17 00:00:00 2001 From: Jan Nieuwenhuizen Date: Fri, 12 Oct 2018 22:02:18 +0200 Subject: [PATCH] doc: Update Preparing to Use the Bootstrap Binaries. * doc/guix.texi (Preparing to Use the Bootstrap Binaries): Mention bootstrap-mes alongside bootstrap-gcc. (Reducing the Set of Bootstrap Binaries): Mention the Reduced Binary Seed bootstrap, MesCC-Tools and Mes. --- doc/guix.texi | 56 +++++++++++++++++++++++++++++++++++---------------- 1 file changed, 39 insertions(+), 17 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index d77788c4e0..41abfa4999 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -23920,8 +23920,8 @@ GNU C Library (@pxref{Bootstrapping}). Usually, these bootstrap binaries are Taking these binaries for granted means that we consider them to be a correct and trustworthy `seed' for building the complete system. Therein lies a problem: the current combined size of these bootstrap binaries is about 250MB -(@pxref{Bootstrappable Builds,,, mes, Mes Reference Manual}). Auditing or -even inspecting these is next to impossible. +(@pxref{Bootstrappable Builds,,, mes, GNU Mes}). Auditing or even inspecting +these is next to impossible. For @code{i686-linux} and @code{x86_64-linux}, Guix now features a ``Reduced Binary Seed'' bootstrap @footnote{We would like to say: ``Full Source @@ -23931,8 +23931,8 @@ to use that term for what we do now.}. The Reduced Binary Seed bootstrap removes the most critical tools---from a trust perspective---from the bootstrap binaries: GCC, Binutils and the GNU C Library are replaced by: @code{mescc-tools-seed} (a tiny assembler and linker) -@code{mes-seed} (a small Scheme Interpreter and a C compiler writen in Scheme) -and @code{tinycc-seed} (the Mes C Library, built for TinyCC). Using these new +@code{bootstrap-mes} (a small Scheme Interpreter and a C compiler writen in +Scheme and the Mes C Library, built for TinyCC and for GCC). Using these new binary seeds and a new set of @c packages@footnote{@c @@ -23988,7 +23988,15 @@ packages bootstrap)} module. A similar figure can be generated with @example guix graph -t derivation \ -e '(@@@@ (gnu packages bootstrap) %bootstrap-gcc)' \ - | dot -Tps > t.ps + | dot -Tps > gcc.ps +@end example + +or, for the Reduced Binary Seed bootstrap + +@example +guix graph -t derivation \ + -e '(@@@@ (gnu packages bootstrap) %bootstrap-mes)' \ + | dot -Tps > mes.ps @end example At this level of detail, things are @@ -24020,10 +24028,10 @@ write them in an output directory with the right layout. This corresponds to the @code{#:modules} argument of @code{build-expression->derivation} (@pxref{Derivations}). -Finally, the various tarballs are unpacked by the -derivations @code{gcc-bootstrap-0.drv}, @code{glibc-bootstrap-0.drv}, -etc., at which point we have a working C tool chain. - +Finally, the various tarballs are unpacked by the derivations +@code{gcc-bootstrap-0.drv}, @code{glibc-bootstrap-0.drv}, or +@code{bootstrap-mes-0.drv} and @code{mescc-tools-boot-0.drv}, at which point +we have a working C tool chain. @unnumberedsubsec Building the Build Tools @@ -24089,7 +24097,9 @@ automated way to produce them, should an update occur, and this is what the @code{(gnu packages make-bootstrap)} module provides. The following command builds the tarballs containing the bootstrap -binaries (Guile, Binutils, GCC, libc, and a tarball containing a mixture +binaries (Binutils, GCC, glibc, for the traditional bootstrap and +linux-libre-headers, mescc-tools-seed, bootstrap-mes for the Reduced +Binary Seed bootstrap, and Guile, and a tarball containing a mixture of Coreutils and other basic command-line tools): @example @@ -24108,12 +24118,12 @@ know. @unnumberedsubsec Reducing the Set of Bootstrap Binaries -Our bootstrap binaries currently include GCC, Guile, etc. That's a lot -of binary code! Why is that a problem? It's a problem because these -big chunks of binary code are practically non-auditable, which makes it -hard to establish what source code produced them. Every unauditable -binary also leaves us vulnerable to compiler backdoors as described by -Ken Thompson in the 1984 paper @emph{Reflections on Trusting Trust}. +Our traditional bootstrap includes GCC, GNU Libc, Guile, etc. That's a lot of +binary code! Why is that a problem? It's a problem because these big chunks +of binary code are practically non-auditable, which makes it hard to establish +what source code produced them. Every unauditable binary also leaves us +vulnerable to compiler backdoors as described by Ken Thompson in the 1984 +paper @emph{Reflections on Trusting Trust}. This is mitigated by the fact that our bootstrap binaries were generated from an earlier Guix revision. Nevertheless it lacks the level of @@ -24125,7 +24135,19 @@ The @uref{http://bootstrappable.org, Bootstrappable.org web site} lists on-going projects to do that. One of these is about replacing the bootstrap GCC with a sequence of assemblers, interpreters, and compilers of increasing complexity, which could be built from source starting from -a simple and auditable assembler. Your help is welcome! +a simple and auditable assembler. + +Our first major achievement is the replacement of of GCC, the GNU C Library +and Binutils by MesCC-Tools (a simple hex linker and macro assembler) and Mes +(@pxref{Top, GNU Mes Reference Manual,, mes, GNU Mes}, a Scheme interpreter +and C compiler in Scheme). Neither MesCC-Tools nor Mes can be fully +bootstrapped yet and thus we inject them as binary seeds. We call this the +Reduced Binary Seed bootstrap, as it has halved the size of our bootstrap +binaries! Also, it has eliminated the C compiler binary; i686-linux and +x86_64-linux Guix packages are now bootstrapped without any binary C compiler. + +Work is ongoing to make MesCC-Tools and Mes fully bootstrappable and we are +also looking at any other bootstrap binaries. Your help is welcome! @node Porting @section Porting to a New Platform