On Fri, Jan 28, 2011 at 1:03 AM, Mathias Krause mathias.krause@secunet.comwrote:
Hi,
flashrom currently tries to unlock the chip before each read/write/erase command. To prevent further modifications of the chip content, e.g. for security reasons, it would be helpful if flashrom would also be capable of the opposite operation. I talked with Carl-Daniel a little about it and he mentioned problems like having to implement features like partial locks, chips that cannot be unlocked after being locked, etc. To support those features and handle the problematic chips something more than this little patch can do must be implemented. But for now it would be nice to have *something*. See it as a starting point to solve the much bigger problem.
Yep, it certainly gets hairy.
On Fri, Jan 28, 2011 at 1:03 AM, Mathias Krause mathias.krause@secunet.com wrote:
This patch adds a function pointer to struct flashchip and a command line option to trigger this function to enable full flash chip write protection. It's currently only implemented for the Atmel AT26DF081A since this is the chip I'm currently working with and which I can test easily.
For what it's worth, we've been doing something similar in the Chromium OS branch (http://git.chromium.org/gitweb/?p=flashrom.git;a=tree). Apologies if it seems a bit sloppy at the moment, we've had to wedge in a lot stuff to solve immediate concerns.
We also added a member to the flashchip structure (.wp), but in our case it is a pointer to a "writeprotect" structure which contains a bunch of function pointers. We felt this was necessary since write protection varies greatly between chips and we want fine-grained control.
In our model, the user specifies the byte range (offset and length) and enables write protection in two steps. For example: "flashrom --wp-range 0x200000 0x200000 --wp-enable".
Most of the ugly stuff in our code is contained within writeprotect.c. So if you want to give it a try it should integrate into your tree pretty easily.