ryan
/
ownerboot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
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.
master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '8c8c0017ca'
${ noResults }
ownerboot/doc/fallback.md

2.2 KiB
Raw Blame History

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. Major chunks of the mechanism were deleted in 2019 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.