The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
This page explains how coreboot can help with various security aspects of your system, compared to closed-source, legacy BIOS/EFI/firmware implementations.
Fixes can take months before being available on non-free firwmares, if you are lucky enough to have them. With free software boot fimrwares, security issues can be fixed, and in coreboot many are.
Security fixes are usually mentioned in coreboot ChangeLog on the blog.
Note that while coreboot itself is free software, many boards still use blobs. Some however don't require any.
Because the boot firmware is the first code that executes on the main CPU, it's an interesting target for rootkits:
- The code that runs first has to load what runs next, so it can patch it. That patch can then in turn patch what's next and so on.
- The code that runs first can setup SMM on X86 or TrustZone on some ARM SOCs. SMM/Trustzone are more powerful than ring0. On x86 devices, non-free boot firmwares have a tendency to put a lot of code to run in SMM. In contrast coreboot keep it to a minimum.
- Being stored in a flash chip, separately from the OS and its data, non-free boot firmware have a tendency not to be updated by the end user, nor reflashed externally. That permits a very high persistency.
Given the above, being able to know what your boot firmware does is very important.
Coreboot is working on reproducible builds. That will permit to verify that a given binary corresponds to a given source code.
However this isn't sufficient to verify that you are running the right binary:
Dumping the flash chip externally is strongly advised for that, since some chipsets makes it too easy for the SMM code to give back (to flashrom) another binary than the one in the flash chip.
Existing security features
Given that, with coreboot, the hardware initialization is separated from the boot logic, many security features are implemented by payloads. Nevertheless, coreboot implement some security features.
|Can open encrypted partition||No||Yes||No||No|
If we, for now, start by assuming that coreboot and what resides in the boot flash is trusted, we then might have untrusted chips in the same device:
The hard disk firmware
References for the current BIOS issues
- Coreinfo as demo payload for coreboot, showing your RAM contents after a cold boot.
RAM wiping after each boot
This is not very useful: The most interesting time would be right before power-off, which could be implemented in SMM. Unfortunately a cautious attacker just pulls the plug.
To prevent reading data after a reboot, a payload could be adapted to clean out memory. Using applications that manage sensible data sensibly (ie. wipe after use) is still a better solution.