This document provides a set of brief Chromium OS design supplements, covering areas related to the file system and autoupdates.
The recovery image performs the actions described in the following diagram:
Firmware Boot and Recovery and Verified Boot documents. The firmware is covered in more detail in the Firmware Boot and Recovery document, but here is how it will work from the autoupdate perspective.
We plan to generally update the firmware after successful boot of a new image that contains new firmware to install, but we will be able to force installation of new firmware before an update is applied if necessary.
The firmware contains a stub that can boot into either of two on-chip boot loaders (A or B). The stub first tries to boot from A. If A's checksum fails, it boots B. If B's checksum also fails, it goes into recovery mode.
The firmware updater is a userspace program that runs on system boot. It performs the following actions:
In this scheme, we take advantage of the fact that we could have two identical system partitions.
Note that this is an early design that may change over time based on feedback.
We use the extra bits in the partition table as follows. Note that we have 8 bits in each byte reserved for the bootable flag. This gives us 7 unused bits per partition for the boot loader.
Open issue: We could use a third system partition. This comes at a cost of space, but lets us always have a backup partition ready, even midway through an autoupdate. If a system partition is 200MB, we might do this. If it's 1 GB, we might not want to.
Updates will be stackable. In other words:
Updates can be applied, one after another as they come out, without a reboot. So, for example, if you boot into version n, then update the other partition to n+1 but don't reboot, you're still running n. Then, if n+2 comes out, we will update from n+1 to n+2 in the other partition, while remaining booted into n.
We will be able to force a reboot should we need to apply an emergency security update.