New subject: SPI controller and Lock bits

2 Oct 2018

      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

Re: [coreboot] SPI controller and Lock bits