[coreboot] [RFC] A more robust fallback system
patrick at georgi-clan.de
Wed Nov 16 21:50:59 CET 2011
Am 15.11.2011 23:42, schrieb Guillaume Knispel:
> We can't put the fallback at the beginning of the image because that
> area can't be locked on the chip we are using. (SST25VF016B)
Thanks! That was the missing part in your scenario. Most current chips
support sector granularity (usually 4kb, sometimes rather weird
combinations of different sizes).
Current idea under consideration: Modify CBFS to work from top to
bottom. That way, you could place all immutable data at the beginning of
the chain (ie. top-most). That way all kind of headers, as well as
fallback-versions of code, can be in the protected area.
If updates fail, some mechanism (counter in nvram, jumper, ...) can be
used to tell the bootblock to use the fallback version.
Of course, this is a rather severe change, but actually not that hard in
implementation: a couple of additions replaced by subtraction, and
different exit conditions. As it also affects payload compatibility
(libpayload and seabios at least), it requires some thought.
The only option I see to lock down your system (given that chip) that
won't change the format will introduce a much more complex CBFS
evaluator: In the easiest case, it would walk the entire flash and
return the _last_ occurrence of the requested file name. As it can't
trust any file headers, it would have to look for headers in 16byte
That's not really a useful solution. ;-)
More information about the coreboot