#5371 NORM Never A: 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:  Never Assigned   
 Component:  ofw - open firmware  |     Version:                   
Resolution:                       |    Keywords:                   
  Verified:  0                    |  
----------------------------------+-----------------------------------------

Comment(by wmb at firmworks.com):

 OFW only disables indexed I/O in the secure boot path.  If olpc.fth is
 used directly from the non-secure boot path, it can still perform SPI
 FLASH updates.  (That is not true for files named "{act,run}os.zip" that
 happen to contain Forth code; those cannot update the SPI FLASH.  The
 controlling factor is whether the load-and-execute was performed from the
 secure boot path.)

 Here is the shortest code sequence that I can think of for reflashing
 "manually" from a bootfw.zip file on a USB key:

 {{{
 ok load u:\boot\bootfw.zip
 ok flash /lzip:data.img
 }}}

 Note that this sequence does not check the security signatures, nor does
 it verify that the new version is more recent that what is already
 installed.  But it does perform the usual sanity checks that the image is
 basically sane - the same checks that "flash" always does.

 I wish that I had factored the secure boot sequence better, creating a
 nicely packaged word for doing just the secure firmware update.  But alas.

 Here is a clumsy sequence that does it:

 {{{
 " disk:" dn-buf place
 get-my-sn abort" No serial number"
 date-bad? drop
 load-crypto  abort" Can't load crypt module"
 " \boot" pn-buf place
 " bootfw" bundle-present? 0= abort" No \boot\bootfw.zip bundle"
 img$  firmware-up-to-date? abort" Firmware is already current"
 fwkey$ to pubkey$
 img$ sig$  fw-valid? 0= abort" Invalid signatures"
 img$ tuck flash-buf swap move  ?image-valid
 true to file-loaded?
 ec-indexed-io-off?  if  ." Indexed I/O restart" cr  ec-ixio-reboot begin
 again  then
 d# 12000 wait-until  \ Wait for the EC to notice the battery
 ?enough-power
 reflash
 }}}

 Only the first line above depends on the device name.

 Hmmm, after going through the exercise of teasing out the above code from
 the secure startup process (omitting all the pretty-boot UI elaborations
 and stuff relating to other files), I'm not surprised that I didn't factor
 the code better.  Factoring in the presence of all that UI stuff would be
 pretty tricky.

 Perhaps we should not try to put that clumsy sequence in an olpc.fth,
 because if we do, then if I did manage to improve the factoring later, the
 "all warts exposed" version might break after wart removal.

 Here is an elaborated version of the simpler recipe, adding an up-to-date
 check, handling multiple devices, and casting into colon definition form -
 but not checking security signatures:

 {{{
 : ?reflash  ( devname$ -- )
    dn-buf place
    " ${DN}\boot\bootfw.zip" expand$ ['] (boot-read) catch  if
       2drop exit
    then
    img$ firmware-up-to-date?  if  exit  then
    " flash /lzip:data.img" evaluate
 ;
 " disk:" ?reflash
 " sd:"   ?reflash
 " nand:" ?reflash
 }}}

 Even with this simplification, I'm not sure we really want to put it in
 the "standard" version of olpc.fth .  I favor making olpc.fth as simple as
 possible (e.g. 2 lines) and letting developers do their updates manually.
 In my experience, explaining the manual procedures is easier and more
 robust than trying to debug failures of the automated script - especially
 when there are multiple versions of that script.

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