[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
01/01: website: reproducible-build-summit-2019: Add "Extreme bootstrappi
01/01: website: reproducible-build-summit-2019: Add "Extreme bootstrapping" section.
Thu, 12 Dec 2019 07:43:06 -0500 (EST)
civodul pushed a commit to branch master
in repository guix-artwork.
Author: Ludovic CourtĂ¨s <address@hidden>
Date: Thu Dec 12 13:42:28 2019 +0100
website: reproducible-build-summit-2019: Add "Extreme bootstrapping"
* website/drafts/reproducible-build-summit-2019.md (Extreme
website/drafts/reproducible-build-summit-2019.md | 60 ++++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/website/drafts/reproducible-build-summit-2019.md
index 81958e7..848acd0 100644
@@ -32,6 +32,66 @@ life on the roof top of the lovely riad that was home to the
# _Extreme_ bootstrapping!
+As part of the discussions about bootstrapping, people noted that Guixâ€™
+is usually ignored from [bootstrapping
+and wondered whether it should be taken into account. In effect, the
+build daemon _emulates_ builds from scratch, as if one had booted into
+an empty machine. It does that by creating [isolated build
+that contain nothing but the explicitly declared inputs. However, the
+build daemon is part of the [Trusted Computing
+Base](https://en.wikipedia.org/wiki/Trusted_computing_base) (TCB): like
+compilers in the â€śtrusting trustâ€ť attack, it could inject backdoors into
+build results. Thus, the question becomes: how can we reduce the TCB by
+removing `guix-daemon` from it?
+Vagrant Cascadian came up with this crazy-looking idea: what if we
+started building things straight from [the
+That way, our TCB would be stripped of `guix-daemon`, the Shepherd, and
+other services running on a normal system. Since Guix has all the build
+information available in the form of
+which are normally interpreted by the daemon, we found that it
+_shouldnâ€™t be that hard_ to convert them to a minimal Guile script that
+would be executed during startup, from the initrd. Some hack hours
+later, we had a proof-of-concept branch, adding [a `(gnu system
+with all the necessary machinery:
+ 1. a function that converts an arbitrary derivation to a linear build
+ script that builds all the dependency graph in topological order;
+ 2. the declaration of an operating system that boots into such a
+ script from the initrd;
+ 3. a function to run [a pure-Scheme SHA256
+ implementation](https://github.com/weinholt/hashing) to compute and
+ display the hash of the build result.
+More on that in a future post!
+We went on exploring the space of what we called â€śextreme bootstrappingâ€ť
+some more. How could we further reduce the TCB? The kernel is an
+obvious target: as long as we use the Linux kernel, we could disable
+many optional features, even perhaps networking and storage drivers.
+Fabrice Bellardâ€™s 2004 [impressive `tcc-boot`
+experiment](https://bellard.org/tcc/tccboot.html) reminds us that we
+could even aim for a bootloader that builds the OS kernel before it
+boots it; this removes Linux entirely from the TCB, in exchange for
+When a [Mirage](https://mirage.io/) developer and hackers familiar with
+[GNU/Hurd](https://hurd.gnu.org) talk about bootstrapping, it is no
+surprise that they end up looking at library OSes and microkernels.
+Indeed, one could imagine booting into a dedicated Mirage unikernel
+(though it would lack a POSIX personality), or booting into GNUÂ Mach
+with few or no Hurd services initially running. That would be a way to
+strip the TCB to a bare minimumâ€¦ It will be some time before we get
+there, but it could well be our horizon!
# More cool hacks
- Ten Years reproducibility challenge