Reduce srcfs / bare-metal image size to no more than 256MiB

[Googulator]

For the Trusted Flash drive project, I have been researching various ways to build some kind of Flash storage (USB, SPI, etc.) that can be verifiably limited to 512 byte capacity at boot, and then fully unlocked later once correct loading of the boot sector (builder-hex0 stage 1) has been verified - all without having to trust some firmware to do the limiting and unlocking.

Some ways to achieve this would be:

• using parallel storage with true address lines, and physically disconnecting/grounding high address lines using a mechanical switch,
• hotplugging SPI flash memory chips (512 byte SPI flash chips do exist, with an interface that's compatible with their larger capacity brethren).

Unfortunately, these techniques all seem to top out at about 256MiB - e.g. 256MiB SPI flash storage is available today, but not 512MiB.

The simplify branch has already achieved a reduction to about 290MiB, so 256MiB seems within reach. Maintaining that goal together with #345 seems rather more difficult, but IMO still doable.

[Googulator]

A helpful resource for this is https://ftp.gwdg.de/pub/linux/rocklinux/ROCK-2.1/ - a large repository of BZ2-compressed source downloads, including for software that's only available as GZ elsewhere, such as bash-2.05b.

[Googulator]

#436 achieves this, but the space left over is not enough for a "trivial" version of #345 to be also included in the 256MiB target.

[ahmedcharles]

https://www.adafruit.com/product/6039

This has an SPI interface and is 4GB?

[Googulator]

Not quite the same interface as an SPI flash chip, but rather SD in SPI mode. Also, it contains an SD-style wear levelling controller, with opaque firmware that can't be audited and may hold subversive code (e.g. returning different source code to the bootstrap process vs to an auditor).

[ahmedcharles]

If that's your concern, then I'd suggest that it would be easier to get bare nand flash chips, an FPGA and program it using yosis to convert spi into nand flash and do the wear leveling yourself, than to fit this bootstrap into 256MB. :)

[Googulator]

That's not a solution - you're trusting the host machine to program the FPGA honestly, and not insert a backdoor.

[ahmedcharles]

I guess I'm not entirely sure why a flash chip without wear leveling support would be more trustworthy than a flash chip with that support? Both are large enough to hide a maliciously engineered payload which can't be detected without knowing what the design should look like and examining it with non-destructive imaging techniques costing thousands of dollars.

And that's ignoring the elephant in the room which is that this project only runs on x86 currently, which is only produced by companies with closed software, which requires that they be trusted. I suppose I'm not sure why 256MB is an interesting limit given that maliciously attacking a popular BIOS/UEFI would be more fruitful than attacking the hardened firmware of a wear leveling SPI NAND chip?

[Googulator]

SD cards and their embedded equivalents don't just have "wear levelling support" beyond what a bare Flash chip has. They also contain stored firmware that has to be programmed using a computer that's presumably running untrusted code. That provides a path for a Karger-Thompson retrovirus (commonly just called a "backdoor" in bootstrapping circles, but it's a lot more than just a classical backdoor) to propagate onto any system bootstrapped using code stored on an SD card. By contrast, the only way to infect a bare, dumb Flash chip with a K-T backdoor is at the circuit level, during manufacturing.

BIOS is indeed a problem currently - for now, I'm mitigating that by requiring that the bootstrap be doable on a system that's at least 15 years old. My target platform for this is currently Socket 775, for which one can still find new-in-box parts manufactured before 2010 that can be assembled to form a complete system capable of executing the bootstrap. This way, the only way a K-T backdoor can propagate to the bootstrapped environment is if it has been anticipating the exact bootstrap procedure used for 15 years. In the future, we intend to support RISC-V, which can usually boot in a "firmware-free" way, i.e. with live-bootstrap's seed being the first machine code the CPU executes. AMD's Socket AM5 CPUs hold some promise too, as they have silicon-level support for loading boot code from USB, originally intended for BIOS recovery purposes, although this possibly involves a boot ROM embedded in the CPU, which could be hard to audit, but at least not prone to modification after manufacturing.