[coreboot] SPI controller and Lock bits

Sam Kuper sam.kuper at uclmail.net
Tue Oct 2 13:48:32 CEST 2018


On 02/10/2018, Nico Huber <nico.huber at secunet.com> wrote:
> Am 02.10.18 um 11:53 schrieb Sam Kuper:
>> On 01/10/2018, Youness Alaoui <kakaroto at kakaroto.homelinux.net> wrote:
> tldr; whether the effort to disable write protection is reasonable
> or not depends on what you want to write protect.

Agreed.


> 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.

In principle, I agree. But in practice, Librems don't seem to possess
this kind of separation (yet?).


>>> 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.

That was not my understanding.

See this outline of a putative "BadHeads" attack:
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3

Also see Kyle Rankin's apparent confirmation that such attacks succeed
(on current Librems):
https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4

If I was mistaken about this, then I apologise.


> 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.

Does this mean that Peter Stuge's suggestion to (de-)solder a typical
SPI flash chip's write-protect pin was erroneous?

https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-_peter_stuge#webm


> 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).

I agree about not leaping to conclusions. Sorry if it seemed that this
is what I was doing. A couple of posts back, I did try to make clear
that I believe security improvements in the firmware will be valuable
(albeit probably not sufficient; i.e. a hardware switch of some kind
would also be helpful).


> Also, Sam, you seem to be pushing for a hardware addition that suits
> [wanting] to install updates that you just compiled yourself.
> But that's not everybody's use case.

Whether the context is a solo user, a small organisation, or a large
one, it seems to me that upgrading at least *some* parts of the
firmware should require physical access.

As for how much effort it should be to gain that physical access, I
agree with your implicit point that if changing the root of trust is
separated from upgrading other parts of the firmware, then it may make
sense for the former, which should probably be done only rarely, to be
effortful (e.g. to require removal of the bottom case, and use of ESD
precautions). This would reduce the risk of a passer-by being able to
change the root of trust on a laptop that someone has accidentally
left running and unlocked for a moment while going to the bathroom or
whatever.



More information about the coreboot mailing list