Re: [coreboot] SPI controller and Lock bits

[Peter Stuge]

Youness Alaoui wrote:
> We don't have/use ChromeEC and I think that telling every user that
> they'd need dedicated hardware to update their BIOS makes no sense.

I think you can decide what hardware your products include, right? I
meant dedicated hardware on the mainboard.
> > > Looking for a software solution is IMO like Intel trying to secure SMM.
>
> I don't see why that would be true, the software solution is pretty
> simple. You boot, you can write to the flash in a secure environment,

Intel also considered SMM a secure environment, until they realised
that it isn't. These days I think they consider ME a secure environment.

//Peter

SPI controller and Lock bits

[Sam Kuper]

I have been giving Youness's reply some thought.

On 29/09/2018, Peter Stuge  wrote:
> Youness Alaoui wrote:
> > On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper  wrote:
> > > Relevant URL:
> > > https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect
> >
> > We don't have/use ChromeEC and I think that telling every user that
> > they'd need dedicated hardware to update their BIOS makes no sense.
>
> I think you can decide what hardware your products include, right? I
> meant dedicated hardware on the mainboard.

I think Youness's point, essentially, was that with:

- Heads running from the ROM chip; and
- suitable secrets sealed in the TPM; and
- additional suitable secrets sealed in a Nitrokey;

any additional dedicated hardware on the motherboard would be
unnecessary in order to achieve:

- a "secure", pre-OS environment in which to upgrade Heads; and
- a way to prevent the OS from flashing the ROM.

(Youness, please correct me if I misunderstood you.)

That is all good stuff, and I want it to be achieved. However, I don't
think it goes far enough.

I know that several Chromebooks, as described at the URL above,
include a hardware switch (typically implemented as a screw or bolt
acting as a *latching* SPST switch) that allows ROM flashing to be
enabled/disabled. This seems to me a step in the right direction, but
I don't think it goes far enough, either.

Personally, I would prefer that, in addition to the Heads approach, a
hardware switch should be present, but unlike on the Chromebooks it
should be a *momentary* switch that stays in the write-protect
position by default, and that has to be held in the write-enable
position in order for the flashing process to be able to begin.
(Essentially, a "dead man's handle" or fail-safe.) This mitigates two
potential attack vectors:

1. a user, after she sets her Chromebook-style latching hardware
switch to write-enable and flashes the ROM, forgets to set the
hardware switch back to write-protect, leaving the ROM vulnerable;

2. a remote attacker finds a way to write a "badHeads" to the ROM from
the OS.[1][2][3]
> > > > Looking for a software solution is IMO like Intel trying to secure
> > > > SMM.
> >
> > I don't see why that would be true, the software solution is pretty
> > simple. You boot, you can write to the flash in a secure environment,
>
> Intel also considered SMM a secure environment, until they realised
> that it isn't. These days I think they consider ME a secure environment.

Ouch! It's unkind to liken Heads developers to ME developers... :p

- Sam

[1] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-w...

[2] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-w...

[3] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-w...