[coreboot] SPI controller and Lock bits

Peter Stuge peter at stuge.se
Tue Oct 2 15:29:44 CEST 2018

Sam Kuper wrote:
> > But...
> > there are technical pitfalls that leave the same problem for a momentary
> > switch: Unless you use real custom chips, you'll have to use the access
> > protection current chips support and in the case of SPI NOR flashes
> > there usually is no simple on/off signal that tells the chip to deny
> > writes. Usually, you only signal it to protect its write-protection
> > configuration which you could forget to set correctly after flashing
> > too.
> Does this mean that Peter Stuge's suggestion to (de-)solder a typical
> SPI flash chip's write-protect pin was erroneous?

Indeed soldering the WP#-pin to ground is not sufficient to disable
writes on any and every flash chip, but for chips where writes *can*
be disabled electrically it is the key step that overrides software.

Many flash chips support a write enable policy for parts and/or all of
the chip. (See status register/block protect bits in flash chip data
sheets.) The WP#-pin usually controls whether software is allowed to
change that policy. If the WP#-pin is connected to ground then the
policy can only be changed from write-enable to write-disable, but
the other way around requires disconnecting WP# from ground first.
(That's what a switch would do.)

It is worth noting (I think I mentioned it in that talk) that not
all chips store the policy in non-volatile memory - only some do!

Some flash chips forget the write-protect policy on reset, meaning
that the WP#-pin has no effect from reset until a software-issued
command sets a write-protect policy.

That's potentially a problem if something can access the flash chip
before the x86 root-of-trust runs.


More information about the coreboot mailing list