[coreboot] SPI controller and Lock bits

Nico Huber nico.huber at secunet.com
Tue Oct 2 11:49:35 CEST 2018


Am 28.09.18 um 03:20 schrieb Prasun Gera:
>> The problem is we want to allow users to update their flash and
>> coreboot doesn't have a "flash update utility" integrated, so it has
>> to happen in the payload, which is why coreboot needs to not lock
>> anything then let the payload do the locking for us instead. Heads is
>> the linux-based payload we're using, and the idea is that Heads would
>> lock the flash before it actually boots any OS (from HDD or from USB),
>> this way you can only update your flash from within Heads itself and
>> Heads will ensure that the image you're trying to flash is properly
>> signed, or that you authenticate first before it would allow you to do
>> that (prevents someone from booting into a live USB and flash a
>> malicious bios).
>>
> 
> 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 ?

IIRC, HEADS already reuses a lot of common software, e.g. PGP for sig-
natures, flashrom for flashing. So the bulk of the implementation is
not tied to a specific payload. Actually, we use a similar scheme and
(lib)flashrom in our payload for years. I guess the only thing missing
for a common solution would be a scheme or configuration file format to
discover the update.

And there is also vboot. Which is already implemented in coreboot and
might even provide better security. It's not tied to any specific pay-
load.

Nico
-------------- 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/20181002/a93dea56/attachment.skr>


More information about the coreboot mailing list