#5371 NORM Update.: You cannot do a secure flash of the firmware if you have a developer key

[Zarro Boogs per Child]

#5371: You cannot do a secure flash of the firmware if you have a developer key
----------------------------------+-----------------------------------------
  Reporter:  AlexL                |       Owner:  wmb at firmworks.com
      Type:  defect               |      Status:  new              
  Priority:  normal               |   Milestone:  Update.1         
 Component:  ofw - open firmware  |     Version:                   
Resolution:                       |    Keywords:                   
  Verified:  0                    |  
----------------------------------+-----------------------------------------

Comment(by cscott):

 I like the last version; it seems reasonable and not too bulky.  I'd
 suggest wrapping this as a definition of a word 'check-for-reflash' or
 some such.  Then olpc.fth would check to see if 'check-for-reflash' was
 defined, and define it (as above) if it was not, then execute that word.
 This allows us to change how we do this in the firmware in the future w/o
 breaking anything: we can just define 'check-for-reflash' to either Do The
 Right Thing or else Do Nothing At All, depending on how our future selves
 decide to approach the issue.

 This should be relatively low-risk in any case, because olpc.fth is only
 executed by people with developer keys, who can access the OFW prompt and
 work around any issues if they every arise.

 On the other hand, we've already shipped q2d05 and q2d06 on hundreds
 (thousands?) of machines, which means that update.1 will probably contain
 a firmware update.  We have a little bit of time to figure out what the
 Right Thing is and bundle it in q2d08 (?).

 I actually prefer to put most of the boot logic in the insecure case
 inside olpc.fth, since this ensures that people who want to do Very
 Different Things with the device can do so without working around too much
 hard-coded boot logic.  If you've got a developer key, OFW should be doing
 as little hard-coded stuff as possible.  olpc.fth already has logic for
 invoking 'alt boot'; I don't think this is appropriate for pushing into
 OFW's insecure boot sequence.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5371#comment:4>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system