me/guix
Archived
1
0
Fork 0
Code Activity

doc: Update Preparing to Use the Bootstrap Binaries.

Browse source 
* 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.
This commit is contained in:
Jan Nieuwenhuizen 2018-10-12 22:02:18 +02:00
parent 1a99a9c45c
commit d0bb7ed61e
No known key found for this signature in database
GPG key ID: F3C1A0D9C1D65273
1 changed files with 39 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
doc/guix.texi
View file

@ -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