Choosing hardware for bootstraping and diverse double-compiling

Not all the issues affect everybody in the same way, so it's still good to fix them.

For instance for the Management Engine or equivalent, even if it's present in most recent computers, in some cases it's possible to avoid it completely.

For storage devices (SSD, HDD, etc) firmwares, it's still possible to workaround by booting off an SPI flash or raw NANDs and using LUKS on the mass storage device in a way that makes it very difficult for the firmware to attack the host system through modification of the data as everything is encrypted on it. For instance Coreboot/Libreboot+GRUB or u-boot/barebox + Linux + an initramfs can achieve that pretty easily.

So being able to take out of the equation the compiler and what was needed to produce it (both the software and hardware) also makes trusting the software much more easier.

In the case of Mes, as I understand it, it still depends on the system used to do the compilation which includes both the software and the hardware. In addition, getting the same binary out of a diverse double-compilation only ensure that either the backdoor is the same or that both have no backdoor.

The issue is also that while we have some information on real world attacks (XcodeGhost) and that we basically know what it takes to do very simple compiler modifications that propagate themselves inside subsequent compilers being built, it's hard to really understand the threat as some of the companies and government agencies that work on offensive security have large budgets and try to keep a big part of their work secret. In addition, not everything they do is published (for instance Edward Snowden probably didn't retrieve and give everything that he had access to to the Journalists which probably didn't publish everything either).

That said, if we want to bootstrap a C compiler, we still need hardware and software.

If I understood correctly with something like the stage0 implementation, we won't need a kernel nor an operating system, and given enough work it could be used to somehow bootstrap a compiler, kernel and operating system.

So I wonder what type of hardware would make sense to run a stage0 implementation:
- If you use Coreboot / Libreboot on a desktop (to avoid the issue of the embedded controller) with an I945 chipset (as there is free code to initialize the GPU / display controller), and find peripherals that you can somehow trust, you still end up having to build Coreboot / Libreboot, so it's probably not the best option here. And you probably cannot review the assembly of the Coreboot / Libreboot image as they are way too big. As for writing a smaller version of them, they'd probably still end up being quite complex if we need RAM or access to a display controller. We can use the CPU cache as RAM quite easily though, but I'm unsure if that would be sufficient for the display controller part of the GPU and a very basic stage0. Installing that code would also be quite challenging as you'd need to trust some SPI flash programmer as well.
- Another approach would be to find an ARM SOC that has a bootrom that has been dumped and reviewed where users can easily input code and that has a display controller that don't need complex software to be used. This still bring in the hardware as something users have to trust blindly.
- Yet another approach would be to use FPGAs like an ECP5 with something like LiteX and the free toolchain for it. Here you could review the HDL code but this brings in way more software dependencies as you need to actually produce the FPGA image.
- Another option would be to use very old and well known hardware (like an Altair 8800) and somehow manage to use that to bootstrap the stage0. Though they are probably not always easy to find.

There are also procedure in place that could increase trust through randomness: the key signing ceremony, which is a procedure to setup an HSM can also be modified to be used for installing software but not necessarily for producing it.

For instance if you want to install Coreboot / Libreboot and that you trust your SPI flash programmer and can build an image in a reproducible way, you can get random computer, remove the radios, install the software to talk to the SPI flash programmer and make all of them read/write the image to the SPI flash in a random order without giving any of them the ability to know if there will be another computer that will do the same thing right after. This way any computer can detect if what's on the SPI flash is what is supposed to be there or if another computer has modified it. None of the computers will also be able to predict if they'll be the last computer to check that flash chip.

Denis.