[coreboot] SPI controller and Lock bits

[Nico Huber]

Am 02.10.18 um 13:48 schrieb Sam Kuper:
> 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?).

The software doesn't. But it's much easier to add it later once the
hardware supports it. IMHO, design decisions for future hardware should
prepare for state of the art security and not the security of yesterdays
soft/firmware.

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

Sorry, I won't have the time to read through all this. In theory, it
depends on when the measuring is started. If the measuring starts only
late in HEADS (and not in coreboot), you are right. Generally you'd have
to tamper the piece of software that starts the measuring.

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

No, I wouldn't think so (without watching that video). What I meant is
that lifting your finger from a momentary switch won't be enough. You,
or the software you use, could still "forget" other things with the same
effect. The problem is that what the flash chip does when the /WP pin is
asserted usually depends on the chip's configuration (that you might
have to change to be able to flash; depends on the chip I guess). Just
read your chip's datasheet if you want to know the whole story.

Nico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xBD56B4A4138B3CE3.asc
Type: application/pgp-keys
Size: 5227 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181002/5b109830/attachment.skr>