11d3605b08
This is the last LTS version buildable using GCC 4.0.x. The next one, version 4.19, requires at least GCC 4.6. Fortunately, this is also the first version of the Linux kernel without firmware blobs being included in /firmware, so the FSFLA deblob scripts aren't needed anymore to ensure a fully auditable kernel - the 3 remaining drivers that do include blobs masquerading as source code are removed via a patch, avoiding all the other side effects of the deblob scripts. This doesn't compromise the trustworthiness of the bootstrapped environment, since all the other drivers deblob would remove use the firmware loader mechanism, which does nothing when the actual firmware blobs aren't installed on the system separately. Features dependent on firmware still won't work, but many drivers that load firmware do so only optionally. This includes r8169, the driver for the Realtek gigabit NICs found on many x86 motherboards. This kernel is considerably larger than 4.9.10, and we build more of it (including drivers that would previously get stripped away by the deblob script, such as r8169), so to accommodate that, Fiwix initrd size is increased by 64MiB, while lowering kexec space by the same amount to ensure enough userspace memory available in Fiwix. Fiwix's maximum open file count is also bumped from 1.5K to 2.5K. The Documentation folder is deleted before build, to further save space in the ramdisk. |
||
|---|---|---|
| .github/workflows | ||
| .reuse | ||
| LICENSES | ||
| builder-hex0@a2781242d1 | ||
| lib | ||
| seed | ||
| steps | ||
| .gitignore | ||
| .gitmodules | ||
| DEVEL.md | ||
| README.rst | ||
| download-distfiles.sh | ||
| parts.rst | ||
| rootfs.py | ||
| source_manifest.py | ||
README.rst
live-bootstrap
An attempt to provide a reproducible, automatic, complete end-to-end bootstrap from a minimal number of binary seeds to a supported fully functioning operating system.
How do I use this?
Quick start:
See ./rootfs.py --help and follow the instructions given there. This uses a variety of userland tools to prepare the bootstrap.
(Currently, there is no way to perform the bootstrap without external preparations! This is a currently unsolved problem.)
Without using Python:
git submodule update --init --recursive
Consider whether you are going to run this in a chroot, in QEMU, or on bare metal. (All of this can be automated, but not in a trustable way. See further below.) a. chroot: Create a directory where the chroot will reside, run ./download-distfiles.sh, and copy:
System Message: ERROR/3 (<stdin>, line 35)
Unexpected indentation.
The entire contents of seed/stage0-posix into that directory.
All other files in seed into that directory.
steps/ and distfiles/ into that directory. * At least all files listed in steps/pre-network-sources must be
System Message: ERROR/3 (<stdin>, line 39)
Unexpected indentation.
copied in. All other files will be obtained from the network.
Run /bootstrap-seeds/POSIX/x86/kaem-optional-seed in the chroot. (Eg, chroot rootfs /bootstrap-seeds/POSIX/x86/kaem-optional-seed).
System Message: WARNING/2 (<stdin>, line 42)
Block quote ends without a blank line; unexpected unindent.
QEMU: Create two blank disk images. * On the first image, write
System Message: ERROR/3 (<stdin>, line 44)
Unexpected indentation.
seed/stage0-posix/bootstrap-seeds/NATIVE/x86/builder-hex0-x86-stage1.img to it, followed by kernel-bootstrap/builder-hex0-x86-stage2.hex0, followed by zeros padding the disk to the next sector.
System Message: WARNING/2 (<stdin>, line 47)
Block quote ends without a blank line; unexpected unindent.
distfiles can be obtained using ./download-distfiles.sh.
See the list in part a. For every file within that list, write a line to the disk src <size-of-file> <path-to-file>, followed by the contents of the file. * Only copy distfiles listed in steps/pre-network-sources into
System Message: ERROR/3 (<stdin>, line 52)
Unexpected indentation.
this disk.
Optionally (if you don't do this, distfiles will be network downloaded): * On the second image, create an MSDOS partition table and one ext3
System Message: ERROR/3 (<stdin>, line 55)
Unexpected indentation.
partition.
System Message: WARNING/2 (<stdin>, line 56)
Block quote ends without a blank line; unexpected unindent.
- Copy distfiles/ into this disk.
Run QEMU, with 4+G RAM, optionally SMP (multicore), both drives (in the order introduced above), a NIC with model E1000 (-nic user,model=e1000), and -machine kernel-irqchip=split.
System Message: WARNING/2 (<stdin>, line 60)
Enumerated list ends without a blank line; unexpected unindent.
c. Bare metal: Follow the same steps as QEMU, but the disks need to be two different physical disks, and boot from the first disk.
Background
Problem statement
live-bootstrap's overarching problem statement is;
> How can a usable Linux system be created with only human-auditable, and wherever possible, human-written, source code?
Clarifications:
- "usable" means a modern toolchain, with appropriate utilities, that can be used to expand the amount of software on the system, interactively, or non-interactively.
- "human-auditable" is discretionary, but is usually fairly strict. See "Specific things to be bootstrapped" below.
Why is this difficult?
The core of a modern Linux system is primarily written in C and C++. C and C++ are self-hosting, ie, nearly every single C compiler is written in C.
Every single version of GCC was written in C. To avoid using an existing toolchain, we need some way to be able to compile a GCC version without C. We can use a less well-featured compiler, TCC, to do this. And so forth, until we get to a fairly primitive C compiler written in assembly, cc_x86.
Going up through this process requires a bunch of other utilities as well; the autotools suite, guile and autogen, etc. These also have to be matched appropriately to the toolchain available.
Why should I care?
That is outside of the scope of this README. Here’s a few things you can look at:
- https://bootstrappable.org
- Trusting Trust Attack (as described by Ken Thompson)
- https://guix.gnu.org/manual/en/html_node/Bootstrapping.html
- Collapse of the Internet (eg CollapseOS)
Specific things to be bootstrapped
GNU Guix is currently the furthest along project to automate bootstrapping. However, there are a number of non-auditable files used in many of their packages. Here is a list of file types that we deem unsuitable for bootstrapping.
- Binaries (apart from seed hex0, kaem, builder-hex0).
- Any pre-generated configure scripts, or Makefile.in’s from autotools.
- Pre-generated bison/flex parsers (identifiable through a .y file).
- Any source code/binaries downloaded within a software’s build system that is outside of our control to verify before use in the build system.
- Any non-free software. (Must be FSF-approved license).
How does this work?
For a more in-depth discussion, see parts.rst.
Firstly, builder-hex0 is launched. builder-hex0 is a minimal kernel that is written in hex0, existing in 3 self-bootstrapping stages.
This is capable of executing the entirety of stage0-posix, (see seed/stage0-posix), which produces a variety of useful utilities and a basic C language, M2-Planet.
stage0-posix runs a file called after.kaem. This is a shell script that builds and runs a small program called script-generator. This program reads steps/manifest and converts it into a series of shell scripts that can be executed in sequence to complete the bootstrap.
From this point forward, steps/manifest is effectively self documenting. Each package built exists in steps/<pkg>, and the build scripts can be seen there.