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. //Peter -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
