[coreboot] SPI controller and Lock bits
sam.kuper at uclmail.net
Sat Sep 29 10:58:48 CEST 2018
I have been giving Youness's reply some thought.
On 29/09/2018, Peter Stuge <peter at stuge.se> wrote:
> Youness Alaoui wrote:
>> On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper <sam.kuper at uclmail.net> wrote:
>>> Relevant URL:
>> 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
>> > > 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
More information about the coreboot