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

[Mathias Krause]

On 01.02.2011 20:41, David Hendricks wrote:
> 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).

Actually that is a good thing. At least unexperienced users might want
to check different ranges and see if it works for them, before locking
the status register down.

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

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