I am reading the "flash security recommendation" from PCH BIOS writer guide now, it did say strongly recommend to take those actions. The EISS feature to ensure BIOS region can only get modfiyed from SMM.
On Wed, Sep 26, 2018 at 7:01 AM Nico Huber <nico.hu...@secunet.com> wrote: > 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 > executed). > > 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). > > Nico > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
