@Insurgo
I see that you updated the above posts. Some people, including some core developers, are interacting with this forum via email. They do not receive the edits made after 10 minutes. For this reason, it’s better to make a new post, not update the old one (and/or use quotations like I do below).
Here are your edited posts for them
@Demi :
Heads packaged cryptsetup1 initially. To have support for TPM released Disk encryption key, cryptsetup2 needs to be in the firmware, you are right. The user could theoretically still boot their laptop by typing their LUKS disk encryption key passphrase. But they could not install Q4.1 without having done the firmware upgrade first, read below on the whys.
@Sven The firmware update is not only for that LUKS2 support, but to resolve graphical glitches that were not permitting Qubes 4.1 graphic installer to be launched without a coreboot upgrade (coreboot+vbt). Otherwise, users attempting to install Q4.1 would face QubesOS 4.1 installer doesn't boot on sandy/ivy bridge (xx20/xx30) · Issue #789 · linuxboot/heads · GitHub graphical glitches, and Qubes installer just fails after a while, trying to work in text-based version which is not aimed to be functional under Qubes even today.
Unfortunately, this is why things are complicated, since how Heads was deployed before Maximized builds existed (legacy boards).
I can try to summarize here again real short. Initially, Heads was aimed to not interfere with ME. Since the Intel Firmware Descriptor is normally locked, and the BIOS region is normally protected, Heads and Skulls required an external initial flash of the 4mb top SPI chip present in xx30 boards (the X230 was the first board to land under Heads).
Neither Heads nor Skulls required the end user to do anything with the 8mb bottom SPI flash. Still today, legacy boards do not expect the user to have neither unlocked the IFD or have neutered ME to take advantage of the freed space there. So Skulls and Heads (x230-flash) prepared 4mb roms to be flashed to the top SPI, and then flash internally the 7mb bios region, respecting the BIOS region defined under IFD.
The reasoning of this comes from the alignment of the BIOS region, which is spanning across the two SPI chips. See the flash layout here: Lenovo Ivy Bridge series — coreboot 4.22-679-gcc2ab49525 documentation
So to unlock IFD and neuter ME, the 8mb chip needed to be backuped and those instructions needed to be followed Cleaning Intel Management Engine | Heads - Wiki. ME was neutered, consequently, but the ME freed space was not made available to the BIOS region. The only way to do that is to also change the IFD with a smaller ME region matching its size, and the BIOS region expended (maximized) to take advantage of the freed ME space (bringing the BIOS region available space from 7mb to 11.5mb). This is what Maximized boards are.
1vyrain project landed, and was able to chainload exploits to bypass BIOS protections, mainly from S3 resume path vulnerabilities to unlock the BIOS region and be able to flash 4mb ROM images (Heads x230-flash and Skulls), permitting the end user to then flash the 7mb BIOS region contained under the invalid 12MB image (x230 legacy rom does not contain a valid IFD and is only flashing the BIOS region defined under the IFD). But it is not possible to unlock IFD nor ME regions internally. An initial external flashing of an unlocked IFD and ME region is required.
The PrivacyBeast shipped with IFD unlocked (as opposed to the NitroPad in the past). The PrivacyBeast permits users to upgrade to maximized boards, internally, but with a manual flashrom invocation, since maximized roms contains a valid IFD, a valid neutered ME and a valid GBE region. And because the ME region and IFD regions are unlocked.
So a PrivacyBeast owner can move away from legacy to maximized roms, manually upgrading once from the recovery shell by doing:
- mount-usb
- flashrom --force --noverify-all -p internal -w /media/PathToMaximizedRom.rom
Otherwise, the GUI will try to overwrite the 7mb BIOS region with a 11.5 BIOS region, which of course would result in a brick
All future firmware upgrades will flash the whole 12mb rom internally from the GUI. But the initial upgrade needs to be manual, which floods my support channels.