Heads/Coreboot specific work #

[zaolin]

Heads/Coreboot specific work

@zaolin

• [ ] Properly support Intel based, most binary free initialized platforms in coreboot (Ivy Bridge and Sandy Bridge). This implies integrated Measured boot improvements that landed in Coreboot 4.9+, which sits atop of VBOOT and to change Head's internal logic to take advantage differently of TPM PCRs to have proper and mainstreamed BIOS integrity measured. Technically, it means:
  • [ ] integrate/ test :
  • [ ] Add VBOOT support
  • [ ] Enable VBOOT support
  • [ ] check if fmap is correct
  • [ ] set CMOS flags correctly
• [ ] Support TXT in Coreboot/Heads, so that [QubesOS Anti-Evil Maid](https://www.qubes-os.org/doc/anti-evil-maid/) can be used with coreboot Open Source Firmware. @marmarek said this was not considered a necessity. A discussion should be engaged between you two before going forward. (see here)

Originally posted by @tlaurion in https://github.com/osresearch/heads/issues/540#issuecomment-519188762

[zaolin]

We will scope that out. Let me come back to you. Regarding Intel TXT @marmarek any input?

[zaolin]

We need to discuss the security model with flash chip.

[tlaurion]

@zaolin I'm ready! Some links to share?

[marmarek]

AEM in its current form is about boot integrity (xen.gz, vmlinuz, initramfs) only. It is doing that through TXT/DTRM. Heads provide very similar assurance with SRTM + a more convenient verification method (NitroKey with green/red LED or dynamic TOTP). We don't have other usage for TXT in Qubes right now. There are some wild ideas about doing re-attestation after S3, but I think it isn't even properly designed yet.

[tlaurion]

@marmarek @zaolin AEM official doc: https://github.com/QubesOS/qubes-antievilmaid

[merge]

We need to discuss the security model with flash chip.

Not sure if that's what you mean, but in case it is, this is my view: vboot "RO" and heads will lock the flash (even if we don't yet do that now. should be an easy addition).

[zaolin]

@merge Yes but updates rely then on heads

[merge]

@merge Yes but updates rely then on heads

sure. just as they do already I guess.

[tlaurion]

@zaolin @merge

Yes. The updates should come from Heads reproducible builds anyway and are updatable from whiptail menus already.

The user puts a reproducible rom on a usb disk, go to Heads settings menu, selects the flash rom update, and decides if he wants to wipe the currently added cbfs files in its current rom or not.

Keeping current configuration (user modified /etc/config overrides and public gpg key) are exported from cbfs regions prior to be reinjected in rom and then flashed back into spi with flashrom.

Reflashing modifies measurements and requires the user to seal those in the TPM/Librem Key and reseal a new disk unlock key depending of current board configurations.

[tlaurion]

@zaolin the lockdown part, in heads, would be #326

[tlaurion]

The general goal here is to broader the range of FSP free, neutralized+deactivated Intel ME (and PSP absent) boards supported under Heads umbrella, while taking advantage of coreboot's measured boot support available through VBOOT work merged under coreboot 4.9+. Heads currently uses an in-house measured boot support based on coreboot (4.8.1).

Upon completion, it is expected that the following boards will be supported under Heads with latest coreboot.

First importance:

• X230
• T530
• T430

Second importance:

• T420
• X220 (To be reviewed after https://github.com/osresearch/heads/issues/616 interactions)

General

• Heads needs to upstream coreboot to its latest version
  • As per past debates, Heads reproducible builds needs to use coreboot "stable" and tested revision, used across all supported boards. It cannot use coreboot's master moving HEAD under Heads.
    • Consequently, a precise, tested commit ID or coreboot release is preferred.
    • On which patches applied to coreboot can be applied under Heads until next coreboot release.
• Under coreboot 4.8.1, coreboot was patched to have measured boot working without VBOOT
  • Note that all other patches were upstreamed to coreboot and are not needed in earlier coreboot versions.
• Heads toolstack (common for TPMTOTP and HOTP) will need to be modified to take newer PCR into consideration
• FMAP will need to be rewritten/reconsidered
  • Most of the actual boards have Intel ME that can be neutralized (using only 90Kb) which leaved a lot of SPI space to be used for Heads.
  • On a sidenote, if there is any idea coming within the scope of this work to attack space constraints that we have for other smaller SPI chips boards (X200 non-vPro 4Mb, G505s 4Mb and others), please advise.

coreboot 4.8.1 specifics

• X230 has an additional 5Mb that could be used by Heads if flashmap was defined correctly after Intel ME properly neutered. If there was a way to generate FMAP consequently to available space in the 12MB rom, that would be amazing. see #307
• X220/T420 has a delay of 50 seconds booting heads. It seems to be a wait and timeout communicating with Intel ME. The same applies to the T420 and all other boards, except the x230. Why?

Tickets needing to be updated/closed with the work being done here: https://github.com/osresearch/heads/issues/41#issue-181472484 https://github.com/osresearch/heads/issues/500 https://github.com/osresearch/heads/issues/287 https://github.com/osresearch/heads/issues/562 https://github.com/osresearch/heads/issues/541 https://github.com/osresearch/heads/issues/150 https://github.com/osresearch/heads/issues/15 #307

[tlaurion]

"Also, keep in mind assembly is a lot more work for the t530, you have to solder a wire to the opposite chip your flashing every single time and so on to bypass flash protection (cs to vcc)"

[tlaurion]

Work continuing under #709 (9elements) #721 (community)