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
On Wed, 04 May 2011 12:35:54 +0200 Michael Karcher flashrom@mkarcher.dialup.fu-berlin.de wrote:
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?
i dont like the term "precious regions", but apart from that i think for the described problem a layout file-based solution alone is not ambitious enough.. it even complicates things, because we need an extra step to generate the layout file. i have not looked at the code yet, but generally the desired information needs to be gathered from several sources. in the case of ICHs some pci registers of the (internal) programmer have to be read; for some hardware protected flash chips it is possible to read the wp status in their status register(s); there may also be other limitations like maximum address lines for parallel flashers (what else?). these can and should be read dynamically and evaluated before starting to erase/write in combination with the information from the layout file (precedence on the dynamic data with an enforcing option in the layout file?). so we would need a data structure (probably similar to what now holds the layout from the layout file), querying methods in all kinds of objects in flashrom and something that evaluates the data structure before committing modifying commands. all in all this stuff is quite convoluted. i think we should not start before we have reduced the patch backlog significantly. a part of what i think can certainly be hacked into ichspi.c quite quickly but i think to mitigate the outstanding ICH problems for the near future the backup idea is better.
i see the java programmer shines a little bit through... but i really like generic solutions :)
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.
this is the way to go for -w/-e for now imho. we should also print a big fat warning when we do probe (or -r) and notice some possible problems for other operations (i.e. r/o or locked regions).
Am Mittwoch, den 04.05.2011, 13:59 +0200 schrieb Stefan Tauner:
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?
i dont like the term "precious regions", but apart from that i think for the described problem a layout file-based solution alone is not ambitious enough.. it even complicates things, because we need an extra step to generate the layout file.
I didn't think of implementing precious regions *via* a layout file, I just mentioned that for EC/boot block, some subimages in the layout files should be markable as "precious". I am open for other terms, too.
i have not looked at the code yet, but generally the desired information needs to be gathered from several sources.
That's correct.
in the case of ICHs some pci registers of the (internal) programmer have to be read;
for some hardware protected flash chips it is possible to read the wp status in their status register(s);
While we also might want a kind of locking infrastructure, which might share code with what I thought of for the precious regions, this still is something different. A flash chip that has some write protection does not get into unfixable state by issuing an erase command, but it will reject the erase command.
there may also be other limitations like maximum address lines for parallel flashers (what else?).
IIRC we reject working with non-addressable chips (parallel with too few address lines, or non-mapped FWH).
these can and should be read dynamically and evaluated before starting to erase/write in combination with the information from the layout file
The data we get dynamically is qualitatively different from the data in the layout file. The layout file tells us about the logical structure of the flash, while the dynamic data tells us about the physical limits. In case of the ICH stuff, on some layer these two views happen to coincide, as the physical locking is indeed enforced on the base of the specified logical structure. But for example on some parallel flash chips, the chip might have a read-only top boot block of 16K, while the boot block code of the BIOS is in fact 32K or 64K. For deciding what we should rewrite, we need the true logical boot block size, while for knowing what can be erased, we need the physical boot block size.
all in all this stuff is quite convoluted. i think we should not start before we have reduced the patch backlog significantly.
Agree. I just wanted to archieve the idea.
a part of what i think can certainly be hacked into ichspi.c quite quickly but i think to mitigate the outstanding ICH problems for the near future the backup idea is better.
I never thought of an ichspi specific solution, that's why I didn't call it something like "firewalled regions", but looked for a more general concept of "for some reasons, do *never* *ever* erase this range".
i see the java programmer shines a little bit through... but i really like generic solutions :)
If you are a java programmer, you are most likely gonna hate the limited ad-hoc OO-like structures in flashrom.
[Abort on possible problems of ICH]
this is the way to go for -w/-e for now imho. we should also print a big fat warning when we do probe (or -r) and notice some possible problems for other operations (i.e. r/o or locked regions).
Who will make a patch for that, me or you?
Regards, Michael Karcher
On Wed, 04 May 2011 14:51:41 +0200 Michael Karcher flashrom@mkarcher.dialup.fu-berlin.de wrote:
Am Mittwoch, den 04.05.2011, 13:59 +0200 schrieb Stefan Tauner:
in the case of ICHs some pci registers of the (internal) programmer have to be read;
for some hardware protected flash chips it is possible to read the wp status in their status register(s);
While we also might want a kind of locking infrastructure, which might share code with what I thought of for the precious regions, this still is something different. A flash chip that has some write protection does not get into unfixable state by issuing an erase command, but it will reject the erase command.
sure the ICH case is more severe, but a system where flashrom tries to erase+write a partially write-protected chip would also lead to problems and unbootable systems (although they are more easily fixable ofc).
there may also be other limitations like maximum address lines for parallel flashers (what else?).
IIRC we reject working with non-addressable chips (parallel with too few address lines, or non-mapped FWH).
yes, in a non-generic way ;)
these can and should be read dynamically and evaluated before starting to erase/write in combination with the information from the layout file
The data we get dynamically is qualitatively different from the data in the layout file. The layout file tells us about the logical structure of the flash, while the dynamic data tells us about the physical limits. In case of the ICH stuff, on some layer these two views happen to coincide, as the physical locking is indeed enforced on the base of the specified logical structure. But for example on some parallel flash chips, the chip might have a read-only top boot block of 16K, while the boot block code of the BIOS is in fact 32K or 64K. For deciding what we should rewrite, we need the true logical boot block size, while for knowing what can be erased, we need the physical boot block size.
there may be two mappings necessary: one for write, one for erase; but i dont see the point in differentiating between "logical" and "physical". its unimportant for flashrom why exactly it is not possible to write/erase an address region as long as it checks it before it "commits the whole transaction" (i.e. starts to erase and write).
i see the java programmer shines a little bit through... but i really like generic solutions :)
If you are a java programmer, you are most likely gonna hate the limited ad-hoc OO-like structures in flashrom.
i don't hate the structures that try but fail to do the right thing, but the language that hinders us from doing so :P
[Abort on possible problems of ICH]
this is the way to go for -w/-e for now imho. we should also print a big fat warning when we do probe (or -r) and notice some possible problems for other operations (i.e. r/o or locked regions).
Who will make a patch for that, me or you?
i'd like to concentrate on my usb flasher and getting all the/my previous patches in, but i can try too if you dont want to. let's discuss/fix the specification first, which centers on the question: when do we want to abort/warn?
warning could be done by letting "do_ich9_spi_frap" return something instead of void and printing similar to the FLOCKDN warning at the end of ich_init_spi. (btw the FLOCKDN warning should be enhanced: as i said before i think ichspi has very verbose output. those warnings need to stand out more...) we could abort immediately in ich_init_spi by returning something != 0(?). what other options do we have? a file-wide variable that is set by init and is checked by run_opcode?
-
Michael Karcher -
Stefan Tauner