Firmware security

  This page is monitored by the OLPC team.

Scope

!!! NOT YET FINAL (but maybe getting there!) !!!

This page describes the role of Open Firmware in BitFrost security on XO.

Goals

1. Run recovery firmware if primary firmware is bad
2. No access to ok prompt without developer key
3. Firmware update images must be signed
4. Boot images must be signed
5. Unactivated laptops will only boot the activation image
6. Boot alternate OS image if primary OS image is bad

Files

The files listed below are on NAND FLASH in JFFS2. The zip archives listed below must be created without compression (-n option) and without paths (-j option). Implementation notes and rationale are in italics.

• Primary images are in /boot, secondary images are in /boot-alt

  At the start of an upgrade process, boot is copied to boot-alt; this doesn't need to be atomic. When upgrade is complete and validated, the upgraded files will be moved atomically to /boot. The atomic substitution requires /boot to be a symlink to the 'real' boot directory, which will be /boot-XXXXXX, where the X's are chosen by mkdtemp to be unique.

• The activation key is named "/security/lease.xxx". Format and extension TBD.
• The developer key is name "/security/develop.key".

  Rationale: The /security directory is left untouched by the upgrade process.

• The normal OS image is in "/boot/runos.zip", containing "os.img" and "os.key", and "/boot/runrd.zip", containing "rd.img" and "rd.key". An activation OS image is in "/boot/actos.zip", containing "os.img" and "os.key", and "/boot/actrd.zip", containing "rd.img" and "rd.key".
  • os.img is one of the load formats that OFW supports, e.g. Linux bzImage
  • os.key is ASN.1 signature of os.img as defined by the bios_crypto (SHA256->ECC256)
  • rd.img is a ramdisk image in a format supported by the kernel in os.img (typically initramfs)
  • rd.key is ASN.1 signature of rd.img as defined by the bios_crypto (SHA256->ECC256)
  • runrd.zip/actrd.zip may be omitted, in which case runos.zip/actos.zip is booted without a ramdisk.

    Rationale: The ramdisk is only used during activation and certain upgrades. As an optimization, we can skip authenticating and loading the ramdisk when it is not needed in order to simplify and speed up boot. In practice runrd.zip is likely to be a symlink which can be easily deleted and recreated when needed.

• The new firmware image is "/boot/bootfw.zip", containing "bootfw.img" and "bootfw.key"
  • bootfw.img is the usual OFW image format
  • bootfw.key is ASN.1 as defined by the bios_crypto (Whirl->RSA, SHA512->RSA, Whirl->ECC521, SHA512->ECC521)
• The backup files in /boot-alt have the same names and are in the same formats as /boot.

On USB disk or SD card, the files are as follows:

• Only one directory, /boot, containing runos.zip, bootfw.zip, and an optional runrd.zip as before

  Security dicates that we boot from an authenticated filesystem. Rather than have OFW authenticate the full USB/SD contents, we'll boot from an authenticated ramdisk, which can then authenticate whatever other files it needs (if any) from the USB/SD disk. For this reason, there should always be a ramdisk, but it may be monolithic with the kernel in runos.zip rather than in a separate runrd.zip file.

  We should be careful to ensure that the files are authenticated after they have been loaded into memory, to prevent attacks involving switching files between authentication and later use.

Process

1. If OFW fails to come up correctly, a firmware recovery procedure is attempted - details TBD.
2. In the following, the "primary" images are the files in /boot, and the "secondary" images are the files in /boot-alt, unless the "check" gamepad key is held down during boot, in which case the roles reverse: the primary files come from /boot-alt, and the secondary files come from /boot.
3. OFW checks for a new firmware image in the /boot directory on an attached USB, then SD, device. If one exists and verifies, OFW reflashes itself and reboots.

   Upgrade USB keys may contain firmware-only upgrades.

4. OFW checks for a new firmware image in the primary directory in the NAND flash. If one exists and verifies, OFW reflashes itself and reboots.
5. OFW locks out further SPI FLASH writing with the hardware lock.
6. If a valid developer key is present, OFW enters non-secure mode, where it behaves as it currently does. Otherwise ...
7. If the activation key is present and valid (fill in details), the boot filenames will be runos.zip and (if present) runrd.zip. Otherwise, the boot filenames will be actos.zip and actrd.zip.
8. If the activation key is present and valid, we will attempt to verify and boot from the boot files in /boot on an attached USB, then SD, device.
9. OFW verifies and boots from the boot files in the primary directory.
10. OFW verifies and boots from the boot files in the secondary directory.
11. If none of the above booting steps succeed, OFW displays and error screen and halts.

Usage notes

• After boot, userland can determine the source source from the OFW device tree in /ofw/<fill me in>. This can be used to determine whether activation is needed (actos.zip) or whether booting is being performed from the secondary source (boot-alt/*).
• Although outside the scope of this spec, there are primary and secondary filesystem roots in /fsroot and /fsroot-alt corresponding to the kernels in /boot and /boot-alt. /boot/runrd.img will typically be absent to speed boot. However, /boot-alt/runrd.img will typically be required in order to switch to /fsroot-alt so that kernel and userland match. When we clone /boot into /boot-alt at the beginning of an upgrade, we link in an appropriate /boot-alt/runrd.img
• When the alternate kernel is booted and we've switched into /fsroot-alt, we can either:
  1. add a /boot/runrd.zip link so that if we reboot into the primary we can switch the filesystem back /fsroot, or
  2. Swap /boot and /boot-alt, making future boots start this kernel. This option is preferred. We should ensure that we've done another upgrade before we try to boot into a different kernel again.
• We will typically use hard or soft links to avoid storing multiple os and ramdisk images. The current plan is to actually have only one kernel and one ramdisk image; the ramdisk will look at how it was invoked to determine whether this is an upgrade, activation, or alternate boot.

Notes

• I am assuming that the primary use of USB/SD boot is to do OS, firmware, or activity upgrades where bandwidth is a limitation. These can easily be done with the mechanism provided by just sticking a (properly signed) "magic upgrade key" into the USB port and power-cycling.
• USB probing is time-consuming and perilous (although SD is not). At some point (after manufacturing processes are fixed) we'll only try to boot from USB if the 'X' game key is pressed during boot.
• We could be more user-friendly by detecting "failed boot after linux kernel invocation" in some way, and automatically booting from the backup in this case. This seems like post-FRS work.