[flashrom] RFC: precious regions

[Michael Karcher]

Hello flashrom developers,

INTRO (may be skipped):
-----------------------
while I know that I should spend my time for flashrom with polishing my
patches instead of proposing even more changes, I need to write down the
idea about "precious regions", as we had two incidentes of
descriptor-mode ICH southbridges recently. Some of them would have been
prevented by using current HEAD, but even svn HEAD is able to some
destruct typical descriptor mode systems.

Imagine:
  Descriptor: 0-8K (r/o)
  Gigabit: 8K-32K  (r/w)
  BIOS:   32K-2M   (r/w)

flashrom HEAD will first read the whole chip, then try to erase. All
block erase instructions will fail, as the descriptor is r/o. But the
chip erase instruction still can be sucessfully sent, and erase
verification works, too. In the last step, the new image gets written -
but not to the descriptor, as that on is R/O.

IDEA:
-----
Introduce the concept of "precious regions", i.e. parts of the flash
chip that may never be erased. Flashrom would deny to send erase
commands to blocks that overlap with precious regions. This might cause
flashrom to fail in certain cases where a block that crosses a border
between precious and non-precios needs to be erased to modify the
contents of the non-precious region, so "precious regions" should not be
overused (i.e. declare all not-to-be-modified regions from the layout
file as "precious" unconditionally). I see the main use case for
precious regions in these two items:
 - Regions we know we can't write, because of the flash firewall in the
chipset. Most flash chips implement their locks in a way that a
non-programmable area is non-eraseable, so flash chip locks don't need
the "erase forbidden" handling.
 - Embedded controller code and boot block code

precious regions for unwritable areas are mandatory, as flashrom will
leave a messed up system behind otherwise, while precious regions for
boot block and EC code of course should be optional, but are very nice
to have as safety net on computers with soldered flash.

I explicitly don't suggest trying to implement a general algorithm to
find boot block and EC code in vendor images in flashrom, but a
3rd-party tool to generate layout files might be nice. I do think of
extending layout file syntax to be able to flag layout parts (e.g. as
precious, but other flags like "prefer big erase/prefer small erase"
might make sense too), though.

What are your thoughts about this?

BACKUP IDEA:
------------
If the precious region stuff seems as overdesigned, we should abort as
soon as we find any non-rw region on the ichspi driver.

Regards,
  Michael Karcher