[Trac #978] Firmware recoverability and security

[Zarro Boogs per Child]

#978: Firmware recoverability and security
---------------------------------+------------------------------------------
 Reporter:  wmb at firmworks.com    |       Owner:  wmb at firmworks.com
     Type:  defect               |      Status:  new              
 Priority:  normal               |   Milestone:  CTest            
Component:  ofw - open firmware  |    Keywords:                   
---------------------------------+------------------------------------------
 We need to do something about firmware recovery from programming mistakes
 and implement the reprogramming security features.

 The attachment contains some ideas from Quanta that we should consider as
 part of this effort.

 One issue with the "boot block" suggestion is that it would require
 hardware changes to provide some sort of jumper that would select the boot
 block instead of the main area of the firmware.  On old-style parallel-
 accessed FLASH chips, that was easy to do - you  just override an address
 line with a jumper.  It's not so straightforward on the SPI FLASH that we
 use, because all the address bits are sent serially over one wire.  I
 suppose that the EC might have some feature for accomplishing such a
 mapping, but I didn't notice one that last time that I read the EC
 hardware spec.

 We could do a similar thing in software, but it would be somewhat more
 complex than the simple jumper approach.  Ron Minnich has suggested one
 such strategy.

 For example, the very early startup code could live in a "protected" erase
 block by itself, one that is not overwritten during most firmware updates.
 That startup code could check the integrity of the main firmware image in
 the rest of FLASH, and if it is corrupt,  then instead execute a special
 recovery image that lives in the protected erase block.  There are two
 difficulties with this approach:

 a) On OLPC, it is unclear that a recovery image could be dramatically
 smaller than the main image, since OLPC has no external I/O ports that can
 be accessed "easily", i.e. without a complex software stack.  So how would
 the recovery image get the bits necessary to reprogram the main image.

 b) This mechanism might compromise the OLPC firmware security features.

 Instead of having a special recovery image in protected FLASH, it would be
 possible to have two separate main images.  Open Firmware is small enough
 for that to be feasible.  The early startup code in the "protected" block
 could check the signatures of the two images and use the one that is most
 recent, falling back to the other one if the recent one is not intact (as
 indicated by a checksum, which already exists in the Open Firmware module
 list).

 This other approach solves problem (a), and probably also problem (b).
 Since the "fallback" firmware is fully functional, it can have exactly the
 same security mechanisms.  It doesn't have to be a "stripped down" version
 that uses some "back door" mechanism for reprogramming the FLASH.

-- 
Ticket URL: <http://dev.laptop.org/ticket/978>
One Laptop Per Child <http://laptop.org/>