[flashrom] [RFC + PATCH] lock command for flashrom

[David Hendricks]

On Fri, Jan 28, 2011 at 1:03 AM, Mathias Krause
<mathias.krause at secunet.com>wrote:

> 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 at 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.

-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20110128/6050eaf6/attachment.html>