At 33c3 a question came up about "how can we trust and audit coreboot?" compared to things like the Intel Firmware Support Package (FSP). I'm relaying it to the list for discussion.
The FSP is a x86 binary blob that has an init function that writes magic values to magic registers to bring up the mainboard, the DRAM controller and other devices in the SOC.
Meanwhile, many of the coreboot mainboard_init() functions write magic values to magic registers to bring up the mainboard, the DRAM controller and attached devices. For example, x230/mainboard.c:
static void mainboard_init(device_t dev) { RCBA32(0x38c8) = 0x00002005; RCBA32(0x38c4) = 0x00802005; RCBA32(0x38c0) = 0x00000007; }
Do we trust the coreboot version because the C is easier to read than disassembly of the FSP, even though there is about the same level of documentation? What can we do to improve the auditability of coreboot if we don't understand the security implications of these magic values?