[coreboot] SPI controller and Lock bits

Nico Huber nico.huber at secunet.com
Wed Sep 26 16:00:23 CEST 2018

Am 26.09.18 um 10:50 schrieb Patrick Rudolph:
> Hi Youness,
> On 2018-09-26 01:30 AM, Youness Alaoui wrote:
>> Hi,
>> I'm trying to add a way to lock the SPI flash to be read-only via
>> software *after* coreboot boots. The scenario is basically with using
>> Heads, you could authenticate to it (with a yubikey/nitrokey/librem
>> key) then be able to flash a new rom (update your BIOS), but once you
>> boot an OS, Heads would first lock the flash so it can't be written
>> to.
>> This should add some security to avoid any malware writing to the
>> flash, or someone booting into a USB stick and using that to flash a
>> malicious BIOS, but still gives the user the freedom of updating their
>> flash whenever they want to.
>> The problem is that I can't make the flash read-only because the SPI
>> interface is already locked down by coreboot (see
>> src/soc/intel/skylake/lockdown.c and
>> src/soc/intel/common/block/fast_spi/fast_spi.c).
>> There's a couple of things happening here :
>> First, the FLOCKDN bit is set which prevents us from enabling the
>> write protection. the BIOS Interface lock down is controlled by the
>> chipset_lockdown config variable, but the FLOCKDN is not behind a
>> config variable.
>> The second thing is that if I wanted to use the protected ranges
>> feature to lock specific regions, they are all getting locked using
>> the discrete lock register even while being unused. The locking of the
>> protected ranges was added in this change :
>> https://review.coreboot.org/c/coreboot/+/21064 and it passed without
>> notice among the move that the commit was supposed to do.
>> The commit states that the lockdown is meant to "support platform
>> security guidelines", but I think that this is not actually good
>> because coreboot leaves everything read-write and locks down the
>> registers so we can't make it read-only. I think that the security
>> guidelines would say to disable the write protection before locking
>> the registers down.
> Feel free to propose a new "security guideline", but document it in the
> tree.
> A similar mechanism is already implemented on Intel:
> https://review.coreboot.org/#/c/coreboot/+/21327/

Please note this is about having the whole chip protected. But not about
the decision whether or not to lock this configuration. It reminds me of
something, though: If you want to do such configuration in the payload,
both coreboot and payload code/configuration have to be kept in sync
if you have suspend-to-ram. Because coreboot has to do the same confi-
guration as the payload on the resume path (where the payload is not

One way would be to let coreboot decide, e.g. prepare the configuration
and don't lock it, and let the payload lock. The payload could validate
this configuration before locking (and issue a warning if coreboot
didn't set the expected bits).

-------------- 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/20180926/3f3b19e7/attachment.skr>

More information about the coreboot mailing list