Bootstrapping from "Trusted Flash Storage"

A key element to the trustworthiness of the bootstrap process is the small size of the initial binary seed - it's difficult if not downright impossible to hide self-propagating malware capable of compromising the process in 512 bytes, while still maintaining the apparent normal functionality of builder-hex0 stage 1. This can be further enhanced if stage 1 is modified to print out the hex0 source code of stage 2 as it's being compiled, and then stage 2 is likewise modified to print out any readable source code files it loads into srcfs. (Tarballs need special consideration - these would be printed out by untar instead of builder-hex0.)

This way, every byte of code is printed out before it's even compiled, let alone executed - with the exception of the initial binary seed. (Anything else would enable the executed code to modify its own source, and potentially hide malicious functionality from an auditor.) The printout can be securely recorded, e.g. via analog means, and then later reviewed and audited.

However, with normal storage devices, it's really difficult to verify whether the amount of data initially loaded is truly just 512 bytes. A compromised host system, for example, might create boot media with a larger preloader, that emulates the visible behavior of the original 512-byte seed, but secretly does nefarious acts in the background. And as we know from Ken Thompson's talk & paper, it's certainly possible to also subvert analysis tools on the host system, as well as in the compromised bootstrap environment, to not show this preloader or its activity when analysis is attempted.

A way around this is to build the storage device in a special way: with a mechanical switch to limit accessible size to 512 bytes. This should be the direct mechanical and electronic action of the switch, not dependent on firmware running on a microcontroller: in the canonical example, the switch disconnects address lines A9 and higher from a parallel, byte-addressable storage device, so that byte address 512 wraps around to 0. Another way to achieve a similar effect would be hot-swapping different sized SPI flash devices.

To further secure this setup, I'd suggest the following enhancements to stage 1:
* On startup, stage 1 tries to repeatedly read the next 512 bytes of data. Every time it manages to read a block of 512 bytes, it prints that block in hex; every time it receives an error, it prints out an error message. If there's an error, or if the block read matches the first 512 bytes (which is already in memory), it retries. Once it reads a block that's different from itself, it begins loading and compiling the rest, as stage 2.
* Any bytes left empty in the 512-byte boot sector are to be filled not with zeros, but with random data, generated during media creation.

When bootstrapping on bare metal from such media:

1. Set the switch to the "unlocked" position, to enable access to the whole storage. Write the generated image using the host system, then unplug.
2. Set the switch to "locked", and plug the storage device into the target system, the boot from it. Observe stage 1 waiting for stage 2 to become accessible.
3. With the storage still connected, flip the switch to "unlocked" again. If nothing is compromised, stage 1 should stop spin-waiting for stage 2, and start compiling it, while printing everything.

With such a setup, to achieve a compromise, a threat actor would have to encode a backdoor in 512 bytes in such a way to leave room for all the information needed to print out the true, uncompromised stage 1, including the random data used as filler - infeasible even if some form of compression is used.