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

Nobody has claimed this yet.

Some discussion recently over [#OSFW-Trenchboot:matrix.org](https://matrix.to/#/!WHWPvnIGPhGGtUFucJ:matrix.org/$duxf1rs11gNTAnawgFWdcAkc1fSXgNz9BK7G3SE0xhg?via=matrix.org&via=matrix.tu-berlin.de&via=invisiblethingslab.com)

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 https://github.com/linuxboot/heads/pull/1172#issuecomment-1706175050 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.

No source files or tests are named. Start by reviewing this discussion and the conclusions linked from pull request #1172, then identify whether any Optiplex 7010/9010 ACM or TXT support should be removed. Done requires an agreed removal scope and confirmation that the affected platform configuration no longer remains.

Written by the indexing model from the issue text.