Am 02.10.18 um 11:53 schrieb Sam Kuper:
On 01/10/2018, Youness Alaoui kakaroto@kakaroto.homelinux.net wrote:
[...] Youness and others at Purism: if you are reading this, please do spec a momentary switch to control flashing on future Librems. Your security-conscious users will thank you for it.
Yes, I already suggested it for the next iteration.
Great!
It wouldn't be a switch though, but rather a low profile 90-degrees jumper on the motherboard.
This seems to imply that each time a Librem user wants to internally flash the ROM, she would have to:
- power down the laptop(?);
- implement ESD precautions;
- remove the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded inserts;
- remove the bottom case;
- move a tiny motherboard jumper to "write-enable", without losing it;
- power up the laptop with the bottom case off(?);
- run FlashROM (or equivalent);
- power down the laptop again(?);
- move the tiny motherboard jumper to "write-protect", without losing it;
- push-fit the bottom case correctly;
- insert the half a dozen or so tiny bottom case screws, without
losing them, and without stripping their heads or threads or threaded inserts;
- power the laptop back up(?).
Surely, having a momentary switch next to the existing kill switches would be *much* more user-friendly! With such a switch, such a user would just have to:
- hold the switch down while starting Flashrom (or equivalent);
- release the switch and let the flashing process finish.
tldr; whether the effort to disable write protection is reasonable or not depends on what you want to write protect.
You two might have different kinds of updates in mind. You don't need a switch for every update. With a read-only root of trust, for instance, that is secured by the switch or jumper or whatever, you could still update everything else with software only. That root of trust could either verify a signature of the following firmware parts (like vboot does) or start a measuring chain or (ideally) do both.
Separating functional updates from those that change platform-ownership is a key feature of vboot. Without such separation, you'll either make owning too easy or updating too hard.
As for your question earlier about someone forgetting it. I would assume that it would be easy to have the Heads menu show a big warning to the user if it's left unprotected
Your assumption fails against a BadHeads attack.
You need to tamper more than just HEADS, otherwise the attestation of the firmware (e.g. via TOTP or a Librem Key) would fail. So BadHeads seems to be the wrong name here, but I understand your concerns. 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.
What I'm trying to show here is that there is no simple solution that can be implemented in a single spot like putting a switch next to the existing kill switches. One shouldn't rush to implement new schemes that might seem better (compared to the state of the art, which is vboot, imho). If one wants to enhance the security of their next batch of laptops, implementing something compatible to what is already there and has itself proven to work would be a good approach (and it seems to me that is what Youness has in mind).
Also, Sam, you seem to be pushing for a hardware addition that suits your own threat model (which I don't know). I can only assume that you would only want to install updates that you just compiled yourself. But that's not everybody's use case.
Nico