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?
well, my flippant answer is also I think the right one: I don't see a way to build a system I'd trust based on x86 or ARM CPUs any more, and that's why I'm putting all my work into riscv. RISCV is not real, yet, but it's getting there, and the x86 situation has only gotten worse, not better, in the last dozen years :-(
For reasons I don't quite understand, ARM Inc. has decided the x86 model is the right one for ARM v8, and are diving into the UEFI/ACPII tarpit just as deep as they can. I don't understand their thinking.
I don't expect any of this to change; I expect it to get worse. And riscv is no guarantee, either: there are some things built into that architecture that can support vendor mischief, the main one being the requirement to do BIOS calls to do trivial operations, such as enable and reset timer interrupts, or find out your core id. Further, vendors like Red Hat are pushing hard for UEFI and I assume ACPI as the RISCV standard, for reasons I still don't understand. But it ought to be possible to build RISCV systems that are much more trustworthy than the x86/ARM systems.
ron
On 09.01.2017 17:38, Trammell Hudson wrote:
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.
It might have started as that but I believe it's becoming more like any part of UEFI that Intel doesn't dare to push into coreboot. In other words, it's growing faster than hardware initialization demands.
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; }
Just because you see magic values in coreboot doesn't mean that it's not documented. Is this example easier to read than disassembly? for a core- boot developer (who knows a little about Intel chipsets), yes. It even points me to the place in the documentation (southbridge datasheet, SPI controller).
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?
I guess you are right, the readability for itself doesn't provide any better trustworthiness. And there are many cases like the example above, where the implications really aren't publicly documented. Without pro- per, public documentation and the promise by the vendor that this docu- mentation is correct _and_ comprehensive, we can't tell anything about the state of the hardware...
beside the RAM contents and the program we are executing. And this is where coreboot does a much better job, IMO. Given that most host firm- ware stays active during runtime of the OS, I don't see any point in running open-source software for security reasons if there's proprie- tary software running on the same CPU in a higher privilege level.
So what coreboot brings you is what you get from most other OSS: Some eyes on the code that might spot it soon enough if somebody adds a soft- software backdoor. Plus a relatively small code base that has to be watched over.
But for the currently supported modern hardware you don't get more than that (the Quark SoC might be an exception, I haven't checked if its documentation is as open as its firmware). Alas, with coreboot supported systems, it seems the better the support by open software, the worse is the public documentation. Rockchip for example seems to completely lack public documentation.
Nico
On Mon, Jan 9, 2017 at 11:30 AM, Nico Huber nico.h@gmx.de wrote:
Without pro- per, public documentation and the promise by the vendor that this docu- mentation is correct _and_ comprehensive, we can't tell anything about the state of the hardware...
beside the RAM contents and the program we are executing. And this is where coreboot does a much better job, IMO. Given that most host firm- ware stays active during runtime of the OS, I don't see any point in running open-source software for security reasons if there's proprie- tary software running on the same CPU in a higher privilege level.
And at the very least we can verify that the blobs are what we think they are ("good enough" if we can trust the blob's origin) and maintain some semblance of control in privileged mode.
Obviously full documentation and source are best. But in our imperfect world with blobs I think the more relevant question to ask is what can be done before and after the blobs are run. Being able to build a full image with coreboot gives us some options, and having a relatively simple codebase with a decent eyeball-to-code ratio helps. As Nico said it's pointless to run OSS for security if the best you can do is run in less privileged mode with proprietary software in full control.
-
David Hendricks -
Nico Huber -
ron minnich -
Trammell Hudson