EC protection, Librem 14

Greetings, after upgrading the Librem 14 EC firmware I was curious:

  1. Pureboot didn’t complain the EC firmware changed - does it measure the EC, and if not, can/are there plans for it to?
  2. The motherboard’s write protect DIP switches - are they planned to be implemented in the firmware software? If so, I should probably have toggled them.
1 Like
  1. 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

  2. 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 :wink: - 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

2 Likes

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.

1 Like

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!