"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@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@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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot