You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
32 lines
2.7 KiB
Markdown
32 lines
2.7 KiB
Markdown
## Independent Normal/Fallback images
|
|
|
|
This feature is unique to ownerboot, and is not present in upstream coreboot.
|
|
|
|
These images contain two redundant copies of *all* the above components except the bootblock: one for normal use and one for fallback. This allows to test changes to *any* part of the bootloader (including coreboot) beyond the very short `bootblock.c` preamble page, without fear of "bricking" the machine in a way that requires physical intervention. These kinds of "brickings" are inconvenient for both servers in remote data centers as well as for secure laptops for which chassis intrusion (inconvenient when traveling) is the only way to unbrick them.
|
|
|
|
Each image occupies exactly half of the flash image, making it possible to use the write-protect pin (on chips which have it) to independently protect one or both images from persistent malware. Use of the fallback image can be triggered by physically (stylus eject on Chromebooks, recovery jumper/button on KGPE-D16) or electronically (RTC-nvram on amd64 machines, watchdog-driven reboot on arm64).
|
|
|
|
### Relationship to Features Previously in Upstream
|
|
|
|
In the past, upstream coreboot had something called a [fallback mechanism](https://www.coreboot.org/Fallback_mechanism). Major chunks of the mechanism [were deleted in 2019](https://review.coreboot.org/plugins/gitiles/coreboot/+/0e45b2875add588ddada7f40e294db99d62c3c3c) and I was unable to make the remaining vestiges work. Regardless, when it was usable, the upstream mechanism:
|
|
|
|
- Never supported any architecture other than x86.
|
|
- Did not have any ability to trigger a fallback boot via physical means (a button or stylus).
|
|
- Did not use separate CBFS images for `normal` and `fallback` -- they shared a single CBFS image in a single FMAP partition.
|
|
- Used a single `romstage` for both images, meaning that testing a new `romstage` required a "bricking risk".
|
|
- Did not provide any way for `flashrom` to update only the `normal` image, due to using a single FMAP region for both.
|
|
- Could not support flash-chip-level write protection of the `fallback` image (only), due to the images not being aligned on a power-of-two byte boundary.
|
|
|
|
The ownerboot normal/fallback mechanism arose out of a desire to address these issues.
|
|
|
|
### Future Work
|
|
|
|
[This page](https://www.devever.net/~hl/secureboot) has some interesting ideas on how to write protect
|
|
the "normal" image except beween power-on and kexec. This means
|
|
that only the ownerboot kernel/userspace can write to the flash.
|
|
This provides a more secure implementation of the "only the BIOS can
|
|
upgrade the BIOS" restriction (which is actually a software
|
|
restriction implemented in the SMM, which can be vulnerable to
|
|
compromise).
|
|
|