[OLPC-devel] Requirements for a field BIOS reflashing tool.

[Jim Gettys]

On Fri, 2006-06-16 at 18:42 +0200, Stefan Reinauer wrote:
> * Jim Gettys <jg at laptop.org> [060616 17:02]:
> > We are planning, as I believe has been mentioned on the mailing list, to
> > have the embedded controller disable the flash write line unless and
> > until the space bar has been held down for a 5 second period, to make it
> > difficult for worms/viruses to "brick" the machines.
> 
> The 5 second period is a software thing in the flash writer, not a hardware 
> issue, right?

No, the current plan is to enforce this in the embedded controller,
where the flash enable pin is controlled, not in the flash writer.

> 
> I don't think writing should be allowed if I add two lines of spaces in
> the word processor. 
> 
> Many modern motherboards secure their flash write lines using a GPIO 
> that has to be set prior to writing, otherwise not even the flash rom
> identification service will work. 

Exactly: that's what the EC id soing.

> 
> We've been cursing about this stuff in LinuxBIOS a couple of times, when
> it was an undocumented feature ;-)
> 
> >    1) the flash utility would verify a checksum embedded at the end of
> > the flash image, to make sure no bits had been damaged.
> 
> And so should the firmware itself. Assuming that a successful check during 
> OS runtime will result in a successful check during firmware boot time
> can be a wrong implication.
> 
> Running an unchecked firmware image is frivolous. Is there any chance we
> can stuff a "fallback" and "normal" image in the development and/or
> production chips with LinuxBIOS?  The fallback image should just be good
> enough to flash the bios from an external device (floppy, cd, usb stick,
> whatever the final version of the OLPC will allow) as we don't want two
> Linux images in flash under any circumstances.

I don't think we have the space for the luxury of a full Linux as
bootloader redundant image.  There might be something else that could be
squirreled away, but I'm not a LinuxBIOS expert.

> 
> >    2) A additional adder was added, to bring the sum of the checksum and
> > the adder up to a known (to the flash utility) magic number, so we know
> > that it was for the intended model machine.
> 
> An "adder" as in a hardware Manchester carry chain? Usually such
> checksums are CRC16 or CRC32 in safety critical systems.

I didn't write the code, so I don't know the details.

The code can be found (it was written for Microsoft WindowsCE on
handhelds.org

> 
> >    3) the model of machine gets checked against the model(s) the
> > firmware image will work on.
> 
> LinuxBIOS features a model number in flash, and the "flashrom" tool
> which is part of LinuxBIOS checks this prior to flashing.

Great.

> 
> >    8) if there is a problem, try to reflash a time or two more.
> 
> If only to-be-cleared bits are wrongly set, just write it. If bits
> are wrongly cleared, re-erase those parts and try again. Maybe: Check
> if its erased after erasing it.
> 
> >   11) congratulate the user on their success.
> 
> the utility from LinuxBIOSv2/util/flashrom does a lot of this already. 

I don't doubt that the LinuxBIOS flashrom utility does a lot of this
already. I don't have first hand experience with the linuxbios flashrom.

I was trying to document what it took to get something idiot proof on a
machine similar to OLPC in which the boot flash is soldered into the
board so flash chip swaps are not a possibility, and in which the
consequences of idiotic behavior results in a dead,
unrepairable-in-the-field machine.
                                  Regards,
                                         - Jim


> 
> 
> Stefan
> 
> 
-- 
Jim Gettys
One Laptop Per Child