## Why is this necessary?
### Securing a custom BIOS/EFI firmware
If you are f…lashing a custom Coreboot or Heads firmware (BIOS) on your laptop, it's nice to be able to hardware write-protect the SPI flash chip so that an evil attacker can't overwrite your hard work with a #BadBIOS. (Coreboot makes it easy to flash new firmware from software, by default!) This is important enough that the documentation for some custom firmware even [specifies](https://osresearch.net/Heads-threat-model/#system-firmware):
> Finally, once Coreboot has been flashed into the ROM, the write protect pins on the ROMs can be shorted to ground as an extra layer of protection. This prevents any software re-writes of the ROM, even from the Management Engine or other devices on the SPI bus.
This is important enough that this issue has been combined with the [effort to add support for a fully open source mainboard](https://github.com/osresearch/heads/issues/719) to the Heads firmware.
### Defending against BadUSB attacks
Many common USB peripherals can be [modified](https://srlabs.de/wp-content/uploads/2014/07/SRLabs-BadUSB-BlackHat-v1.pdf) [remotely](https://srlabs.de/bites/badusb/) by an attacker to persist or inject malware into the host machine, among [many](http://samy.pl/usbdriveby/) [other](https://samy.pl/poisontap/) potential attacks. The only generally effective way to defend against these attacks and ensure that a USB device remains "clean" is to either choose a [device with no on-board SPI flash chip](https://opensource.srlabs.de/projects/badusb/wiki) or to **disable firmware updates in hardware** by write-protecting the SPI flash chip.
### Write-protecting the Raspberry Pi firmware
Newer versions of the Raspberry Pi single-board computer have a built-in EEPROM for firmware. In order to ensure it's not possible to fully "brick" one, [some](https://github.com/raspberrypi/documentation/issues/1302) users [hardware write-protect this chip](https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2711_bootloader_config.md). Unfortunately, as the documentation notes:
> flashrom does not support clearing of the write-protect regions and will fail to update the EEPROM if write-protect regions are defined.
### Defending against evil maid attacks
As per [this comment](https://github.com/flashrom/flashrom/issues/142#issuecomment-793548441) the [Qubes Anti-Evil-Maid](https://github.com/QubesOS/qubes-antievilmaid) system specifies hardware write-protection for the BIOS, but does not discuss the Status Register Write-Protect issue. Therefore, there are probably many Qubes AEM users depending on this security measure without realizing that it may be useless.
(Naturally, there are [many](https://github.com/rad1o/f1rmware/issues/7) [other](https://github.com/gregdavill/OrangeCrab/issues/27) reasons you might want to hardware write-protect or un-protect a flash chip, these are just a few examples of them.)
### Enabling new approaches to BIOS/EFI security
The Heads BIOS/EFI project has [proposed](https://github.com/osresearch/heads/issues/12) to hardware write-protect only the boot blocks of the firmware image. This would potentially allow users to enjoy the security of hardware write protection while allowing continued software upgrades. However, even basic prototyping of this concept require flashrom to support write-protect.
### Many, many people need this feature
Adding this functionality to flashrom is important enough that, over the last few years, at least ~~five~~ ~~six~~ *a lot* of people have independently written their own patches to implement it:
- the patch included with this issue
- @a-m-joseph 's patch submitted to this issue
- @hatimak 's GSoC patch (described in greater detail below)
- the @3mdeb patch, linked by @tlaurion below
- a patch by @zaolin, described [here](https://github.com/osresearch/heads/issues/12#issuecomment-252022253)
- the [coreboot patch](https://review.coreboot.org/c/flashrom/+/40325) which appears to have been merged on their end
- Martin @sch-m 's [pull request](https://github.com/flashrom/flashrom/pull/60/files) #60
Unfortunately, none of these patches have made it into the main flashrom codebase. As a result, flashrom users are currently doomed to forever repeat the work done by others. They don't realise it has already been done.
As write protect has been independently implemented and re-implemented so many times, there is clearly a pressing need for this functionality to be incorporated in flashrom.
## How flash chip write protection works
Most flash chips have a Write Protect pin that you can solder which will accomplish this goal. Unfortunately, for many flash chips this is easier said than done!
On many flash chips, simply soldering the WP pin to Vcc is not enough, you also have to set some special register bits in the flash chip itself, or else the WP pin is impotent. It does nothing unless the bits are set.
I think Flashrom ought to support setting these bits by default. And it's not just me... others have had enough need for this that there is patch circulating to add this support in a crude way.
Unfortunately, the patch is for a rather old version of Flashrom, and the UX isn't particularly great either. So let's bring things up to date.
## What needs to be done?
Attached is a patch which was written by someone else (they can identify themselves if they like) to toggle the relevant bits for a particular flash chip, each time flashrom is run, and tell the user what's going on.
Your task, if you want to claim the bounty, is to:
1. Add some UI sugar so that the user can choose to set the appropriate bits (or unset them), and any other "features" needed to enable hardware write-protect, via the command line. Desired functionality is *at least* the ability to write protect the entire image, but ideally includes custom block protect settings to enable the Heads special feature research described under "Enabling new approaches to BIOS/EFI security", above
1. Ensure the necessary bits and features can be set for a specified set of chips (see below), so Flashrom supports hardware write protect for at least all of the listed chips, and
1. Get your patch accepted and merged using [Gerrit or the mailing list as per the official process](https://www.flashrom.org/Development_Guidelines#Patch_submission). Flashrom maintainer @i-c-o-n (icon on #flashrom, Libera.chat) is aware that there is considerable demand for this feature.
If $400 isn't enough to make this attractive, I am open to increasing the bounty. I am also happy to escrow it if need be. Payment will be in Bitcoin.
### Current status
(see comments below)
### Patch
[patch.zip](https://github.com/flashrom/flashrom/files/5809788/patch.zip)
See also @hatimak 's work here:
https://blogs.coreboot.org/blog/2016/08/26/gsoc-sr-wp-otp-wrap-up-12/
### Required chips
These are the most common memory chips used in older Lenovo Thinkpads, which are the laptops that people tend to flash a custom BIOS to. If we can support at least these chips, it will make this patch useful to a lot of people. Ideally we would support all the Macronix chips, as they're the most common ones that require software support for hardware write-protection.
_Not all of these may require setting bits in order to activate hardware write protection, please check the datasheets. Depending on the device, the necessary bits may be called things like Status Register Block Protect, Status Register Protect, SRWD, etc. Often it is also necessary to set the Block Protect region (BP0 / BP1 / etc)..._
|Vendor|Device| size|
|--|--|--|
|Eon | EN25QH32 | 4M|
|Eon| EN25QH64 | 8M|
|Macronix|MX25L3206E - MX25L3206E/MX25L3208E|4M|
|Macronix|MX25L6405,MX25L6405D, MX25L6406E/MX25L6408E, MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F, MX25L6495F|8M|
|Micron/Numonyx/ST|N25Q032..1E, N25Q032..3E|4M|
|Micron/Numonyx/ST| N25Q064..1E, N25Q064..3E|8M|
|Winbond | W25Q32.V, W25Q32.W | 4M|
|Winbond | W25Q64.V, W25Q32.W | 8M|
### Other chips it would be useful to support
|Vendor|Device| size| Application|
|--|--|--|--|
|XTX|[XT25F16](https://lcsc.com/product-detail/FLASH_XTX-XT25F16BSOIGT_C558847.html)|16M| Used in USB3.0 hubs (see BadBIOS, above) |