[RFC] obtaining and using field samples of XO system images

[Erik Garrison]

Devel,

-= Some background =-

Today on techteam at l.l.o and security at l.l.o There has been a discussion
of the security rammifications of an automatic save-nand usb key script:
http://lists.laptop.org/pipermail/security/2008-September/000488.html

The immediate use for this script was acquiring system images from the
repair center here at LATU in Montevideo for use in tests of upgrade
procedures.  We need to know if certain failure modes arise commonly on
the deployed systems, but presently there are no field samples to test.
Because there was not immediate support for signing the script I am
using the developer-key approach to copy the images.

In the process of this discussion I suggested that a system-copier USB
script would be a valuable point-of-entry tool for data analysis of our
deployed systems.  Currently such a system does not exist, and we
consequently lack valuable information about the usage of our systems
(XO and Sugar).


-= Question =-

How are we planning on obtaining simple information such as which
activities are most used/downloaded, which ones generate the most data,
common software failures, bug manifestation rate etc.?


-= Proposal =-

The diagnostic process could be as simple from the country's perspective
as: 

  1) dropping a USB key containing the system-copier script into the
     machine in question booting, and waiting for shutdown, 

  2) then inserting the system-copier key (now containing an image of the
     target system) into an XO running an XS build with a diagnostic
     script attached, 

  3) which produces a report and automatically sends it to a server on
     our end for further analysis.

Alternatively a future firmware could provide a menu to all users which
included a nand-save script, but this would not be useful until deployed
systems were upgraded to run it.

We could request that, in order to better our software development
efforts, that a repair center executes this diagnostic process randomly
on machines which come in from the field with problems that are
most-likely hardware-related.


-= Comments =-

Such a system would have been extremely useful during the recent NAND
Full crisis.  During this event hundreds of laptops had to be sent back
to the Uruguay's repair center because their NAND Flash filled with junk
data created by http://dev.laptop.org/ticket/5637.  Obtaining
information about the problem an the state of the machines proved to be
a bottleneck in the resolution process.


Thoughts?


Best,
Erik