Failsafe bootloader

[Jerry Van Baren]

At 05:33 AM 6/4/2003 -0400, Darin.Johnson at nokia.com wrote:

> > Of course, this still doesn't protect you from loading a new
> > bootrom that
> > has a valid checksum but a fatal problem (doh-doh-doh).
> > Fortunately, in
> > that case the idiot is ourselves and we deserve the pain involved, and
> > hopefully learn from it ;-).
>
>The problems we had were first that upgrades could be done
>transparently without the user knowing, so you can't
>really protect from the user unplugging (though we were
>supposed to be an always-on-don't-turn-off product).
>Second, have an image with a good checksum that boots
>up ok is only part of the story, we have to make sure that
>it can communicate correctly on its network.  Ie, the application
>software has to communicate to the boot loader that the new
>image can be kept.
>
>Also from experience, I've really lost a lot of hair in
>situations with other products that say "do not turn off the
>power until this update is finished", only to have the product
>crash, or the computer that is talking to it crashes.

Yes, you REALLY need enough storage to have two copies: the working copy
and the new copy.  The bootrom must NEVER erase the working copy until the
new copy is verified to be completely and correctly loaded (checksums are a
pretty weak validation, CRCs are strongly preferred).

If you are trying to upload a new image in-place, your window vulnerability
(mentioned in my previous email) goes from the amount of time that it takes
to erase and reprogram a block of flash to the time it takes to upload a
program: typically this means going from hundreds of milliseconds
(reasonable risk) to hundreds of SECONDS (extremely high risk).

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/