[coreboot] SPI controller and Lock bits

[Sam Kuper]

On 02/10/2018, Nico Huber <nico.huber at secunet.com> wrote:
> Am 02.10.18 um 13:48 schrieb Sam Kuper:
>> On 02/10/2018, Nico Huber <nico.huber at secunet.com> wrote:
>>> 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.

In principle, I agree. I was just trying to clarify the reason for my
choice of earlier comments.


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

The putative attack bypasses the measuring. As such, I can't see why
it makes any difference whether the measuring starts early (in
Coreboot), or late (in Heads). Sorry if I'm misunderstanding something
basic.


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

On 02/10/2018, Peter Stuge <peter at stuge.se> wrote:
> Indeed soldering the WP#-pin to ground is not sufficient to disable
> writes on any and every flash chip, but for chips where writes *can*
> be disabled electrically it is the key step that overrides software.
>
> Many flash chips support a write enable policy for parts and/or all of
> the chip. (See status register/block protect bits in flash chip data
> sheets.) The WP#-pin usually controls whether software is allowed to
> change that policy. If the WP#-pin is connected to ground then the
> policy can only be changed from write-enable to write-disable, but
> the other way around requires disconnecting WP# from ground first.
> (That's what a switch would do.)
>
> It is worth noting (I think I mentioned it in that talk) that not
> all chips store the policy in non-volatile memory - only some do!
>
> Some flash chips forget the write-protect policy on reset, meaning
> that the WP#-pin has no effect from reset until a software-issued
> command sets a write-protect policy.
>
> That's potentially a problem if something can access the flash chip
> before the x86 root-of-trust runs.

You are both correct that I was assuming a chip that obeys the
write-protect pin regardless of the firmware. I would be surprised if
Purism ordered their motherboards to be built with chips of which that
is not true, but perhaps that was unduly optimistic of me. I have not
attempted to check (yet).

Thank you both for your informative replies :)


Youness and others at Purism: it would be great if Purism could be
sure not only to spec, but also to list on the Librem specification
pages on the website, a SPI flash ROM chip that *does* obey its
write-protect pin regardless of firmware. Thanks :)