Well, they're wrong. The problem is that unless the BMC and BIOS doing all the TPM2_PCR_Extend() calls are securely (like, on some bit of memory or register th

Well, they're wrong. The problem is that unless the BMC and BIOS doing all the TPM2_PCR_Extend() calls are securely (like, on some bit of memory or register that apps can't get to until much later when the secure boot sequence has completed) recording the TPM's resetCount or an audit digest of their commands, then an attacker can reset the TPM at a later point and extend the PCRs with values that are approved, and none will be the wiser. Another problem is that reading out a bitlocker key from the TPM after satisfying a policy is nice, but if it is not read over an encrypted session, then it can be read by any physical attacker than can watch the bus. The fundamental problem, ultimately, is that in order to defeat the bus attacks, the BMC and BIOS and early OS boot stages need secure volatile storage for storing the TPM's resetCount, and long-term non-volatile storage for storing the public key of some primary on the TPM for keying encrypted sessions. An fTPM has no external bus to worry about. Ergo fTPMs are fine.