#2517 HIGH First D: Optimize verification of live incremental upgrades

[Zarro Boogs per Child]

#2517: Optimize verification of live incremental upgrades
------------------------------+---------------------------------------------
  Reporter:  cscott           |       Owner:  mstone                
      Type:  enhancement      |      Status:  new                   
  Priority:  high             |   Milestone:  First Deployment, V1.0
 Component:  upgrade utility  |     Version:                        
Resolution:                   |    Keywords:                        
  Verified:  0                |  
------------------------------+---------------------------------------------

Comment(by cscott):

 I reimplemented this in 545 lines of C.  Speed on XO B4, checking build
 602:
  *  SHA + RMD: 6m 6s (4m30s user)
  *  SHA only:  4m46s (3m11s user)
  *  RMD only:  2m54s (1m20s user)
  *  no hash :  1m37s (   3s user)

 One and a half minutes of the time are spent in the kernel getting the
 data off the NAND.  There's some busy-waiting going on here: dwmw2
 indicated that we need to pause for 1ms to let the data arrive from NAND,
 and if we yielded the kernel, we wouldn't get back for 10ms.

 The RIPEMD160 hash is about twice as fast as SHA256 in this implementation
 (libgcrypt). It's also much weaker than SHA256, but maybe we don't need
 the extra strength.  Clearly we should disable one or the other of the
 algorithms; we can't afford to double our hashing time.

 We might also look for better implementations of the hash functions.
 Libgcrypt has almost certainly not been tuned for our architecture; I
 don't have a good sense for how its speed compares to (say) libtomcrypt or
 openssl.  Getting a little bit more performance out of RIPEMD, for
 example, would make manifest verification really look good.

-- 
Ticket URL: <https://dev.laptop.org/ticket/2517#comment:7>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system