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