[coreboot] SPI controller and Lock bits

[Dhaval Sharma]

"but once you boot an OS, Heads would first lock the flash so it can't be
written to'. Is this some kind of a OS driver? The typical usage of all
locking register which are write once is to have them locked up within BIOS
itself which is within the most trusted boundary. Best we could do it push
out the locking part to the latest stages but not completely out IMHO.


On Thu, Sep 27, 2018 at 9:55 PM Lance Zhao <lance.zhao at gmail.com> wrote:

> Okay, then I believe we should leave the decision on CONFIG instead of
> force lockdown blindly. As of now, that's still optional I believe.
>
>
> On Thu, Sep 27, 2018 at 3:49 AM Nico Huber <nico.huber at secunet.com> wrote:
>
>> Am 26.09.18 um 22:26 schrieb Lance Zhao:
>> > 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.
>>
>> The EISS bit is a highly questionable feature. It's part of the lost
>> cause of security by treating SMM more privileged than the OS. AFAIK,
>> coreboot vendors have secured flash access properly in the past without
>> SMM features and never failed [1]. OTOH, UEFI vendors often granted SMM
>> full flash access in the past and failed to secure SMM [2].
>>
>> To my knowledge, EISS is incompatible to vboot btw. (not by design but
>> to the current implementation).
>>
>> So I "strongly recommend" to ignore Intel's SMM recommendations wrt.
>> flash access and recommend instead to never grant SMM more privileges
>> than the OS.
>>
>> Nico
>>
>> [1] At least since the introduction of SPI flash chips. Earlier there
>>     were possible race conditions regarding the BIOS Write Enable bit
>>     where you needed SMM for protection, or had to use the flash chip's
>>     own security features. But that was before/maybe why EISS became a
>>     feature.
>> [2] e.g.  https://github.com/Cr4sh/ThinkPwn  (the list of vulnerable
>>     systems is long and incomplete)
>>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180927/d8b23319/attachment.html>