4 ms·

You can only flash coreboot if the BootGuard isn't blown. Nothing else will allow you to run coreboot on a mobile Intel platform because the CPU has a hard-fuse

You can only flash coreboot if the BootGuard isn't blown. Nothing else will allow you to run coreboot on a mobile Intel platform because the CPU has a hard-fused hash of the public key for the IBB (boot code in the CPU ROM/factory microcode) and via that, the ACM. (Authenticated Code Module, loaded via ME) This means that you cannot run an Intel CPU without getting an ACM signed by Intel. And that ACM only works with the ME and an Intel formatted SPI flash partitioning scheme. Keep in mind that this hard lockdown only applies to those SoC-ish chips like the mobile PCH+CPU combo chips. Once the PCH and CPU are separate, it's a different story with real options, all the way down to replacing the PCH with one that doesn't have the fuses for BootGuard blown. Manufacturing mode does allow you to access all of the SPI, but it doesn't allow you to add malware of change the firmware as long as BootGuard is still on since you need the RSA private key from the manufacturer to change the firmware, or the RSA private key from Intel to change the IBB+ACM combo package. The Lenovo series you are referring to had a similar but different issue; BootGuard was in validate-only mode, so you can edit the SPI flash and remove the UEFI part, but leave in everything else (ME, GbE, config, IFF, partition data etc.) This has been a non-default configuration for a while, and as you noted, even then it was hard to find one that had that specific firmware/fuse combination. The ME on platforms with sockets is in the PCH which is on the mainboard, not on the CPU, so in theory it is possible to man-in-the-middle the CPU-PCH communication. Another note: a lot of Intel boards have the CCA debug options for ME still enabled due to a mishap from Intel; CCA is the Closed Chassis Adapter which basically runs JTAG over USB3 directly onto the ME CPU core. Getting a USB 3 cable and removing some pins turns it in to a poor man's CCA cable, running some FOSS software on the host will then enable to you stop the ME core on the target and modify memory at will. This basially enables a tethered ME jailbreak, but also ME malware persistence.

userbinator 8y ago
...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.
- 294de3557d9d00b 8y ago
  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/unauthenticated-firmware-chain-of-trust-bypass.html 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 https://twitter.com/qrs/status/1044157473882591233
  - oneplane 8y ago
    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.
- oneplane 8y ago
  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).

userbinator 8y ago

...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.

294de3557d9d00b 8y ago
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/unauthenticated-firmware-chain-of-trust-bypass.html 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 https://twitter.com/qrs/status/1044157473882591233
- oneplane 8y ago
  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.
oneplane 8y ago
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).