File System/Autoupdate Supplements

This document provides a set of brief Chromium OS design supplements, covering areas related to the file system and autoupdates.

Reinstallation

Reinstallation
requires a recovery image (on a USB drive or SD card) to be attached to the system. When
the system boots, the user may force reinstallation by forcing the firmware into recovery mode by pressing a recovery button. The exact details of how the firmware accomplishes this are outside
the scope of this document.

The recovery image performs the actions described in the following diagram:

Firmware updating

The firmware discussed in this document references a firmware designed by Google for Chromium OS-based devices. We recommend that devices that support the Google firmware use that firmware; that lets them take advantage of the boot time, security, and recovery features discussed in the 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:

Bit rot evasion (corruption on the hard drive)

Note: it's unclear how much we expect to be impacted by drive corruption.

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.

0x80

Bootable flag: this partition can be booted. This bit being set
implies that it's a good partition to boot from; it's been vetted.

0x40

Tryboot flag: this partition, which must be bootable, should be booted this time, in the event of multiple bootable partitions being found.

0x20-0x04

Unused.

0x02-0x01

Attempt boot counter, also known as the "remaining_attempts" flag. This takes precedence over bootable/tryboot. For more information, see the File System/Autoupdate document.

The boot loader flow is then:

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.

Stacking updates

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.

Forced reboot

We will be able to force a reboot should we need to apply an emergency security update.