Bootware Firmware Security Issues

From OLPC
Revision as of 02:34, 8 June 2007 by Mcfletch (talk | contribs) (Link to the security category for topics)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The same requirement to protect the bootware described in Threats and Mitigation applies to any persistent mutable state that may be present in hardware devices. At least, unlike a conventional PC, we know precisely what those devices are:

  1. Geode CPU + graphics controller -- no persistent mutable state?
  2. AMD CS5536 Southbridge -- no persistent mutable state. See Boot Options section of datasheet for how it boots.
  3. KB3700-DS-01 keyboard controller -- 128+2048 byte SRAM. Appears to have upgradable firmware, but can be programmed to use only hardware (?)
  4. BIOS -- 1024 KB flash. Main firmware is stored here.
  5. DCON display chip -- no persistent mutable state?
  6. AD1888 audio codec and SSM2211 audio amplifier -- no persistent mutable state.
  7. Libertas 88W8388+88W8015 -- has upgradeable firmware. May have to reflash this in order to recover from infection.
  8. Video camera -- hardware not chosen?

Note that there must be a trusted path to factory-reset the computer (e.g. a button separate from the keyboard, tucked away so that it can't be pressed accidentally, but clearly documented). Having to trigger a factory-reset via software that itself may have been compromised is no good.

(comment from marcs) Trying to be minimalist on required changes to the OLPC hardware, it seems to me that you could get away with having only a trusted path to the selection of the boot media, without a factory reset button. A full OS install from secondary media could (and should) include software to re-flash the firmware. This has the advantage over the factory reset that it would be re-flashed to the latest production firmware version rather than to whatever the version was at the time of hardware manufacture.