After CVE-2018-4251, this is a huge potential security risk.
Apple was quick to fix it last year with an urgent patch. By urgent I mean one that
goes to the next update without delays or next major version, which makes it very
high severity. Also
The attack is rather simple, with this mode on, an attacker can reflash any BIOS region
including Bootguard the ME region with INTEL-SA-00086, and basically persist on the machine
forever, or unless the user reflashes the chip with a physical SPI SOIC-8 programmer.
Do you plan to address this, or at least support locking this as part of with coreboot_util,
while first fusing your (Purism) OEM Public Key Hash to the flash? So that it won’t break
signed BIOS updates to Coreboot or Heads.
Alternatively it will be possible to write a manual of how a user can become his “Own OEM”,
signing BIOS images himself after compilation, but since this is not an easy process I doubt
most users will benefit from that.
I am aware of this “policy”:
Remember, once FPFs such as these are set, they become immutable–permanently fused and impossible to change. The essential part here is to leave them unfused or to fuse them in a configuration that gives the end user control, supporting the best security, privacy, and freedom for users.
Purism’s policy is to ship these unfused, allowing a user maximum control. In the process, we are ensuring that users can use their Purism devices with the ME neutralized and disabled.
In reality, it is almost like saying:
By default we ship our devices without a password for maximum control. This gives the user more freedom etc.
But since most users are unaware of this, actually shipping it “insecure by default” is what makes it not TOFU.