[coreboot] SPI controller and Lock bits

Youness Alaoui kakaroto at kakaroto.homelinux.net
Fri Sep 28 21:25:55 CEST 2018


On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper <sam.kuper at uclmail.net> wrote:
>
> On 28/09/2018, Peter Stuge <peter at stuge.se> wrote:
> > Youness Alaoui wrote:
> >> avoid any malware writing to the flash
> >
> > Just disallow flash writes by the platform. Allow flash writes only
> > by dedicated hardware (maybe ChromeEC?) which implements a simple and
> > efficient security protocol.
>
> 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.

>
>
> > Looking for a software solution is IMO like Intel trying to secure SMM.
>
> Hear, hear!
>

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,
once you decide you don't need to write to the flash, you lock it
until your next reboot.


> This is a pretty useful feature, and it would be nice if it weren't tied to heads (or any payload for that matter). What about tianocore's capsule update mechanism, as well as stuff like fwupd ? Any way to have something like a common solution ?

Tianocore is a payload, so tianocore's update mechanism is still about
doing the update in the payload.. All heads is going to do is to run a
script that calls flashrom (and actually use cbfstool to
extract/inject the heads-specific cbfs files into the new image, such
as the user's pgp keys for example, before flashing).. so it will have
to be tied to heads either way.
Heads is the one booting into your OS, so it can read-only lock the
entire flash before the user (real or malicious) gets control. The use
of heads is already tied in with the use a gpg key (nitrokey, yubikey,
librem key), and you'd already need to have the key inserted (and pin
valid) before it would give you access to a recovery shell, and the
same can be done before it allows the flash to be updated.
I hadn't thought of the use case of fwupd (which we're currently
adding support for) since it wouldn't be able to flash from the OS,
but I think that having the update file deosited in /boot under a
specific filename and rebooting would be all that fwupd would need to
do, then on the next boot, heads would find the file and suggest to
the user to flash it.

> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list