Talk:Firmware security

Several issues with the draft Firmware Security article:

• Developer key should allow reflashing with unsigned firmware. Make it require input from a human on the gamepad.

• Developer key should not be stored in NAND in a particular filesystem format. The user should be free to boot or install new OS's with new filesystem formats, without losing their ability to reprogram the hardware. My suggestion is that the developer key (or a bit or other field that indicates a developer key has been seen) be stored in SPI flash, with or near the manufacturing data.

A developer key is supposed to turn off all the DRM, making it possible for the user to change anything in the system, as if it were an open system. The spec as stated doesn't do that. Open Firmware is freely available for people to modify and run, but even with a devkey, you couldn't run it in an XO (only in somebody else's hardware). That's a bug, not a feature.

I don't think these objections are valid. The current spec says that the developer key drops you into the Open Firmware prompt. From there you can reflash the firmware as you can currently, which could naturally turn off any further key checks. Once you've done that, it doesn't matter if or where you store the developer key, so you can naturally use any flash format you like. CScott 15:11, 14 August 2007 (EDT)

The Open Firmware prompt no longer allows flashing of firmware, CScott. Flashing the SPI flash is disabled in hardware, early in the boot process, UNLESS a signed new firmware image is present. ("Indexed register access" to the EC is disabled, and the EC retains state to prevent future reflashing requested under the EC access protocol.) Please check with Mitch and RSmith re your supposition that "access to the Open Firmware prompt suffices to flash anything you please to SPI", because I believe it is incorrect. Gnu, 21:30, 4 Sep 2007.

• The firmware should refuse to reflash itself over and over. Currently there are a number of endless loops built into the process (e.g. "Look in /boot/bootfw.zip, reflash self if it's newer than current firmware"). I just saw auto-installation go into an endless loop as long as a particular SPI flash image was on USB at boot. When you make a loop like that which runs from NAND there's potential for real trouble, since the user can't just yank the NAND to regain control of their system. This all happens before Linux is booted, before the developer key has been examined, and way before the user gets any control.

OFW could keep timestamps of reflashings; or could, after the third time within ten minutes, ignore the reflash and boot Linux. Or could have a counter and demand human intervention when it hits zero. Or could rewrite the file in the NAND or USB filesystem. Or something!

This is a valid point, but mitigated somewhat if "newer than current firmware" uses the same algorithm that will be used post-boot. The auto-reinstallation scripts have this trouble because "newer than current firmware" relies on a filename check pre-installation, and on some magic bits in the image header post-installation. As long as we use the same method both pre- and post-installation then infinite loops should be impossible. But sanity checks would not be out of place. CScott 15:11, 14 August 2007 (EDT)

Effectiveness of Developer Key Security

I question that the developer key scheme actually protects the firmware -- couldn't anybody with either physical or remote access to the computer acquire and provide the developer key, and use the key to compromise anything they desired?