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

David Hendricks dhendrix at google.com
Tue Feb 1 20:41:57 CET 2011

On Fri, Jan 28, 2011 at 3:00 PM, David Hendricks <dhendrix at google.com>wrote:

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

It seems we keep missing each other on IRC, so let's just continue the
discussion here.

<minipli> dhendrix: I looked at the google flashrom write protect code and
it actually does a different thing then my patch
<minipli> dhendrix: it has the possibility to write protect (and after that,
unprotect again) subranges of the flash memory
<minipli> dhendrix: my patch just enables write protect for the whole chip
and locks the register afterwards
<minipli> dhendrix: the lock, though, is only as effective, as the WP pin
indicates (either hardware locked or software locked)

The Chromium OS code does it in two parts. First, the user specifies a range
(--wp-range). Second, the user enables write protection (--wp-enable).

As I understand, for write protection to take effect the WP pin must be
active. Until that happens, the status register which holds the block
protection status and WP enable bit can be modified by software.

In any case, I believe the ends which you are trying to achieve can be
accomplished using the Chromium OS approach. However, there are many
machines in the field which require partial firmware updates, and thus
cannot be compatible with the coarse-grained approach.

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

More information about the flashrom mailing list