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

David Hendricks dhendrix at google.com
Wed Feb 2 21:30:17 CET 2011


On Wed, Feb 2, 2011 at 2:12 AM, Mathias Krause
<mathias.krause at secunet.com>wrote:

> On 01.02.2011 20:41, David Hendricks wrote:
> > 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.
>
> That's mostly true at least for the chip I'm currently looking at. The
> Atmel AT26DF081A has a status registers with the Sector Protection
> Register Lock bit (SPRL) indicating the lock state of the register - I
> guess any SPI chip has something similar to this. To write protect the
> whole chip a special value must be written into the status register to
> normally r/o fields (XX1111XX binary for "Global Protect"). After that
> the chip is write protected against "accidental write attempts." Write
> and erase commands send to the chip will simply fail. To make them
> succeed the chip must be unprotected first by disabling the global write
> protect. So far so good.
> For security and/or safety reasons one might want to write protect the
> whole chip and prevent undoing the write protect. That's what the SPRL
> is used for. If you set this bit to 1 the status register is locked and
> cannot be modified any further ... well, it depends ;)  If the WP pin is
> connected to GND the lock is enforced by the SPI chip and can only be
> reset through a power cycle of the chip. (Keep in mind, S5 might power
> the SPI chip too, so disconnecting the AC connector may be needed to
> reset this register). If the WP pin is connected to Vcc the SPRL can be
> reset by software, effectively disabling the lock and in turn being able
> to disable the write protection. Not good from a security standpoint.
>
> So to actually write protect a chip the way one would expect it,
> hardware and software must fit together.
>

That is correct. I'm just sayin' that our approaches have the same weakness
:-)

On Wed, Feb 2, 2011 at 2:12 AM, Mathias Krause <mathias.krause at secunet.com>
 wrote:

> > 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.
>
> I see your point of having partial write protects to always being able
> to recover from a bad flash by having a fixed recovery part in the flash
> that won't be overwritten, but as you already mentioned it gets hairy.
> The structure you're proposing has nice features of printing the locking
> capabilities and checking the write protect status. Trying to match this
> to the capabilities of the AT26DF081A, I can just say, it doesn't seem
> to fit.


I just opened up the datasheet for the AT26 part... yikes! I see now that
these parts use a bunch of new opcodes rather than just changing status
register bits.

This is indeed dramatically different than the flash chips I was looking at
(mostly Winbond and Macronix W25 and MX25 chips).

On Wed, Feb 2, 2011 at 2:12 AM, Mathias Krause <mathias.krause at secunet.com>
 wrote:

> (1) The internal sector layout - which must be used, when you
> want partial write protect - is rather scary (the layout looks like top
> to bottom: 32k, 2 x 8k, 16k, 15 x 64k). I don't know how to give this
> information nicely to the user so he can decide which address range is
> required to fit into the locking scheme of the chip.


In the Chromium OS write protection code, we try to abstract details of the
block layout and boil it down to a listing of valid ranges (starting offset
and length). This is pretty easy with the table-driven approach when there
are only 4-32 possible combinations. But as you correctly point out, this
does not really work for the AT26.

For example, if the user wants to block protect only the upper 64KB on the
AT26DF081A, flashrom's write protection code would need to know to map that
to the 32k, 2x 8k, and 16k sectors. Where as if the user only wants to write
protect the bottom 64KB, flashrom only needs to map to a single sector. And
of course there are a lot of invalid combinations as well. What a mess.

I suppose if we were to use the Chromium OS approach for this chip then we
could start by simply presenting the user with one valid option for
--wp-range (start=0, length=0x100000) option which uses the "Protect Sector"
commands on all 16 blocks. Then the --wp-enable command performs the "Write
Disable" command. More intelligent sector handling would need to be added to
deal with finer-grained locking on this chip.

On Wed, Feb 2, 2011 at 2:12 AM, Mathias Krause <mathias.krause at secunet.com>
 wrote:

> (2) Printing the
> write protect status is just not possible because no command to get this
> information does exist. The bits used to enable/disable the global
> protect/unprotect are used for something else when reading the status
> register. The protect/unprotect sector opcodes have no counterpart to
> read out the protection map.
>
> So to just skip all those problems for now I was proposing the simplest
> form of the write protection - just lock the whole chip. This seems to
> be easy for the AT26DF081A and should be so for other chips, too.
>
> Until we* have a better understanding of how other chips use to work,
> this scheme seems to be a start to match some user needs. From a user
> standpoint (the command line interface) this can be easily extended to
> support partial write protect later on, e.g. make -K take an optional
> argument for the address range(s) to protect.
>
>
> Greets,
> Mathias
>
> * Well, at least me, since I don't know much about how flash chips do
>  operate yet.
>

Yes, this approach makes a lot more sense now.

I'm still not sure what the best long-term approach is since my current
focus is kind of narrow :-/

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


More information about the flashrom mailing list