Optiplex 7010/9010 + ACM/TXT : unneeded for now (No DRTM planned for older platforms, No SRTM IBB measured in PCR-0); Removal notice from CircleCI

[tlaurion]

Some discussion recently over #OSFW-Trenchboot:matrix.org

I forgot the context around ACM blobs and coreboot for older Intel generations.

Some context extracted from above Matrix thread, comments from @krystian-hebel (thanks for reminding me of forgotten context):

SINIT ACM for it was dropped from the official package, and it had a bug that wrote wrong value in the TPM event log - normally it should contain input to the extend operation, but for that platform it stored the result instead. It was also heavily impacted by Spectre and friends so it stopped being interesting to Qubes people, so the work shifted to newer platforms instead

Right now the work is centered around AMD client platforms, which should require less blobs to make it happen than server Intel, but thanks for the pointers

The original idea was for Heads to be DRTM-ed, not Heads DRTM-ing other systems. This would limit the amount of required changes to (apart from the kernel entry point, which is being worked on anyway) to switching TPM PCRs usage from 0-15 to 17-22. In case of Heads specifically, this would make it less secure, as coreboot wouldn't be measured, or rather its measurements wouldn't be considered. A better approach would be to use both, but all important parts are already measured somewhere, and moving them around wouldn't improve much (assuming that bootblock is reasonably protected).

tl;dr: Heads is already secure enough that it is hard to improve

kexec approach is much more interesting, but it would mean that the final kernel has to be able to be launched through DRTM, but that requires merging TrenchBoot patches to the kernel, hopefully this will happen at some point in the near future 🤞

Previous discussions happened under #1172 (comment) which conclusions from @miczyg1 were:

Just to clarify the possibilities of TXT measuring the IBB to PCR0, a few things that have to be known:

1. There are two Intel TXT variants: client and server. Each have a different "feature set" and behavior.
2. There are ACM and SACM. The difference is that the latter is Startup ACM, which means it is intended to be run at reset vector. The former are to be run by the BIOS code. There is a bit in the ACM header that indicates if it should be run at reset vector or not. (https://cdrdv2.intel.com/v1/dl/getContent/315168 Table 4 bits 6-7 to distinguish server/client TXT, and ACM heard in APPENDIX A ModuleSubType, although the description is misleading because 0 doesn't necessarily mean SINIT ACM, the real BIOS ACM vs SINTI ACM info is described by ChipsetACMType in Table 10 - yeah confusing...)
3. Client TXT BIOS ACMs are not SACMs, thus the CPU does not run it, despite it is present in FIT. Server TXT ACMs are SACMs and are run at reset vector and those MEASURE IBB.
4. The ProDrive Hermes board (C248 chipset, Cannonlake/Coffeelake) platform is considered as an entry server board based on client Cannon Lake H chipset, so no server TXT SACMs for it... What is considered a genuine server board then? Probably something between Xeon Scallable Processors (or basically anything that can do two sockets and more). A few codenames that are genuine servers: Purley, Whitley (IceLake-SP), Skylake-SP, CascadeLake, CooperLake, Sapphire Rapids, Emerald Rapids.
5. Of course, trying to run the Server TXT SACM will fail because of CPU or chipset mismatch.
6. It May require setting the TXT bit in the ME and running SPS firmware. When the TXT was set, the status bits in CPU TXT registers did change.

We got to these conclusions with @ansiwen when researching the TXT IBB measurement possibilities.

tl;dr

Unless you have a real server board, don't go with TXT to measure IBB, you have to provision BootGuard for it...

EDIT: Of course CBnT supported silicon (i.e IceLake+, CometLake-S +, TigerLake+) is another thing. IIRC no matter if you use BootGuard (with measurement) or TXT, IBB will be measured.

[tlaurion]

Track discussion to see if OptiPlex still considered for validation :
https://matrix.to/#/!WHWPvnIGPhGGtUFucJ:matrix.org/$m-FdpUkY7z0PhkzdLX9VtqK_un8cyaU1t6vMR3XXBLg?via=matrix.org&via=matrix.tu-berlin.de&via=invisiblethingslab.com

[tlaurion]

For Heads, there were two different interests with ACM/SINIT for older platforms (where it seems bootguard provisionned is necessary, still unclear if needs to be fused or not. Bot still desired):

1. IBB measurements from ACM : have additional blobs, but finally get attestation of what is executed on reset/resume path (measurements of bootblock that cannot be compromised, with tpm stack in bootblock per CONFIG_TPM_MEASURED_BOOT_INIT_BOOTBLOCK=y. But as commented in issue; it seems that ACM was bogus, and bootguard required. So void.

• Note that CONFIG_TPM_MEASURED_BOOT_INIT_BOOTBLOCK is enabled only when ACM provided, otherwise CONFIG_TPM_INIT_RAMSTAGE=y

  • Documented as best effort under https://github.com/linuxboot/heads/blob/master/doc/security-model.md

    • Yes, this means bootblock caches measurement of itself, measures next stage which does the same and only when tpm stack ready (ramstage) is those previous cached measurements actually extended to TPM. ACM+IBB measured in PCR-0 from reset vector was a hope to bring back trust anchor into bootblock (and move RoT from bootblock/ramstage -> ACM, litterally), since Heads could then have PCR-0 populated by ACM as part of sealed/unsealed secrets.

2. DRTM itself, from coreboot/Heads and then kexec-tools.