...only until someone finds a bypass for BootGuard, which might actually exist. I'm not too optimistic, but I hope so --- and seeing the reactions of different groups when/if it happens will be interesting to say the least.
We've been hunting for leaked keys, broken IBB's and ACM's for a while, but no real structural thing found so far.
There was a Gigabyte implementation that had a broken HOB response meaning you could boot even with unsigned firmware because the BootGuard handler always returned true. Then there was the lenovo one with BootGuard not even enabled, and there was one compal designed board that had BootGuard enabled but no keys fused. (MFG mode open as well)
Most of the implementation don't use Intel's reference with the logic bug, but an AMI or Phoenix or Insyde implementation.
But still hopeful to find a way to serve a bad ACM, mod the IBB (microcode update attack vector perhaps), or find a way to have the ME report fake values for the fuses (since the values are communicated buy the ME OS to the CPU).
CVE-2018-12169: Platform sample code firmware included with Haswell, Broadwell, Skylake, Kaby Lake, Coffee Lake and Cannon Lake processors contains a logic error allowing a physical attacker to bypass BootGuard firmware authentication. https://edk2-docs.gitbooks.io/security-advisory/content/unau...
"also potentially allows a developer to "jailbreak" their BootGuard protected laptop since the UEFI DXE volume can be replaced with a user provided LinuxBoot ROM image": https://twitter.com/qrs/status/1044157473882591233
Well, LinuxBoot is more like heads (the kernel based pre-boot environment), which was possible for a while now (because the DXE was often not required to be signed for BootGuard to be happy).
If we could do coreboot with only the FSP as blob, that would be cool. We'd still have the ME glued in tho, so not complete free booting there yet.
Also, sadly, most firmwares out there don't have that 1:1 edk2 code in their firmware.
