This is definitely one of the most frustrating aspects of working within the TPM ecosystem. Sure the spec is messy, and doing simple things can feel needlessly complicated, but when you run into some firmware bug, it's horrible to debug, and the best you can really do is file a ticket with Intel/AMI/whoever and pray for something to change.
I never worked too closely with TPMs, just looked at the code in a previous employer because it was adjacent to mine and helped tprefactor some of it. Settings them up was kinda nightmarish considering all the failure modes, and things were not getting much better over time and with new hardware.
The idea with TPM was KISS/separation of concern/"do one thing only and do it well". That is: guard a secret and use it as a trust root.
For some reasons — unrelated to this mission — that simple concept led to an explosion of API entry points covering more an more weird corner cases that ought never to have been included in the trusted platform module. Adding insult to injury, the implementations were developed as closed source in a fashion not unfamiliar to printer firmware — huge code bases full of bugs at any level.
At the core, a trust root can only be trusted when its validity is unquestionable. That is usually a Herculean effort. Think medical/space/aviation embedded devices, open unambiguous spec and implementation, formal verification, lots of eyes, paperwork blablah. That's a lot of money spent on a ridiculously simple component with little to no ways to monetize. No surprise that Intel, AMI, Apple went their own ways yielding mostly opaque, buggy trust anchors that subvert progress of downstream OS development while adding almost no practical security at all.
I think a lot of Linux vendors have missed a trick by giving away TPM support for free.
I mean, the architecture of the TPM has more holes than swiss cheese, and a competent user can achieve higher security without using it.
There are clear benefits of the TPM for e.g. organisations so big that users forgetting their disk encryption password is a substantial support issue; corporations making TiVo-ized products that want to lock out the device owner; and corporations that need to comply with security requirements imposed by the technically clueless. Organisations who have bottomless pockets.
This seems like exactly the sort of features that belong in the Enterprise Edition of your product, like FIPS certification and SAML support.
Oh, it can - the issue I hit here was one that's very similar to an issue I'd hit where the Boot Guard PCR 0 measurement simply wasn't logged at all. The vendor fixed it. I don't want to argue that that's the common outcome, but it's definitely not impossible.
