Greetings, after upgrading the Librem 14 EC firmware I was curious:
Pureboot doesn’t measure the EC. We may add that feature in the future, but there’s no good way to do so besides reading the EC from flash and hashing it (which isn’t very fast). And would require adding additional tooling to Pureboot, which isn’t easy for a few reasons
you should leave them unset (off) until such time as we implement WP using them
I discussed exactly that with @Kyle_Rankin, because I wondered about the same happening (nothing) after upgrading EC.
@nicole.faerber writes in here post about the L14:
"DIP switches (circled in red):
Main PCB, top side, BIOS and EC flash + write protect DIP switch circled in red
These are connected to the write protect pins of the BIOS and EC flash chips! With these you will be able to write protect the chips so that software can not write to them anymore. We still need to add software support for write protect so this is still work in progress."
This might be a good counteraction to the missing heads support for checking on the EC.
But there’s still - at least in my head 
- one piece of information missing I already asked for in another thread: How does the switch actually work. @Kyle_Rankin already offered his state of knowledge, but @nicole.faerber didn’t confirm it. Is @Kyle_Rankin right with his description?
If the purpose of this is to have a higher security and a better integrity one has to accept some more time needed for this. It is never an argument to say that something takes to long if there is the need for a certain level of security. This i the trade-off between living in a “walled garden” or “digital nursing home” and wanting/needing a certain level of security and risk management.
The switch connects to the write protect pin of the flash chip. The function of that pin is a bit awkward, it does not just flat out write protect the whole chip, as one would probably assume, but it prevents the write protect flag being remove from write protected pages. This flag is something that the flashing software can set during writing to the chip. All unprotected pages stay unprotected regardless of the state of the WP pin.
So this means that the flashing software needs to support protecting the flashed pages. And here is the problem, we currently use ‘flashrom’ for all of that and this does not (yet) support protecting pages - as far as I know at least.
Cheers
nicole
not sure why you cut off the 2nd sentence to that question, it’s the larger impediment to validating the EC firmware.
on SPI flash chips, there are registers on the chips which allow for specific address ranges to be marked as protected/read-only, and a bit to enable/disable write protection. The !WP pin (active low) on the chip, when grounded, prevents writing to those registers. The DIP switches control the state of the !WP pin on the main firmware and EC firmware flash chips.
Now, we need a way to set the protected address ranges and enable write protection. That’s handled by flashrom, but the main (upstream) version we use doesn’t support this feature yet (it’s WIP). Google’s fork of flashrom does, but the implementation is messy and there’s a few other reasons we’re not using it.
Thanks for the good explanations to @nicole.faerber and @MrChromebox !
P.D. The quote I cut, because I do not have a say in the work to be done on pureboot to realize protection by heads for the EC. I just believe that it true that it’s not easy to implement.
Maybe I overreacted a bit on the word “slow” as I would have also done for “inconvenient” or “complicated” in the context of security ;-). Sorry if I did!
@nicole.faerber Do you know if the BIOS+EC write protection functionality was ever implemented? Does the switch actually do anything today?
Yes, the switch does something, as it toggles the #WP (write protect) pin on the respective SPI flash chips. But in contrast to what one could assume that this would immediately write/erase protect the chip it only prevents pages of flash content to be non-software eraseable that have been previously marked as “write protected”. So this in the end means that the software writing to the flash chips needs to support setting this write protect flag. And right now neither the EC flashing tool does support this nor does flashrom for the main BIOS - and we simply have not had teh time to implement and/or push this forward yet. But the hardware is there to support it. If someone wants to have a look at it, it’s all open source, we would gladly accept patches!
Cheers
nicole
@nicole.faerber Is there some technical documentation around this? I’ve never worked with firmware or hardware, but I am a software engineer, so perhaps I could give this a shot if you can give me some code pointers.
As far as the BIOS goes:
It does look like the ChromeOS version of flashrom supports write protect.
This issue on flashrom’s Github lists some flashrom forks forks with write-protect patches, including coreboot’s fork.
In May 2022, write protect support for some chips was upstreamed to the official flashrom repository.
PureBoot uses flashrom version b1f858, which is from Sept. 24, 2020. Is it just a matter of updating Purism’s flashrom fork to a recent commit, and adding the write-protect option to the command-line arguments in the flashing script?