Firmware Security/lang-es

  Esta página está supervisada por el equipo de OLPC.

NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... Please leave suggestions on the talk page.

Scope

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

{{{1}}}

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 (if present) 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

{{{1}}}