Except that it can't actually do that, because x86 DRTM doesn't remove SMM handlers installed by the system firmware, ACPI tables also remain resident and could be changed to contain malicious code, etc.
DRTM does not remove any malicious firmware provided code or data. Traditionally it is merely a measurement mechanism that happens after ExitBootServices which measures platform state in an unforgable manner. Practically the DRTM event can also cause certain chipset registers to get locked or SMM supervisors to get launched depending on the platform. SMM and ACPI tables (on some x86 platforms certain tables are rebuilt) are measured into a PCR by the secure loader or security processor during the DRTM event. The idea is that if malicious code or data was present then the PCR values wouldn't match the previous boot session and TPM secrets wouldn't unseal.
While what you said is technically correct, it is by design and any compromised firmware can do as it pleases before the DRTM event at the cost of getting caught and having the device fail attestation or not be able to access encrypted data (depending on what policy is layered on top of DRTM itself as it is just a security primitive). By having PCRs get reset during the DRTM event secrets are much more reliably able to be sealed to specific PCR values.
The claim that SMM is measured by (Intel) DRTM is interesting. Do you have any details on that? To my knowledge Intel was trying to solve this issue using the concept of an 'SMM Transfer Monitor (STM)' not simply by measuring the SMM environment [1]. But it's been 8 years since [1] was written so if you have links to more current information, it'd be welcome.
Unfortunately, I don't believe there is any up to date and detailed public documentation on the modern DRTM flows that exist on both Intel and AMD platforms. Maybe documentation has been recently updated but I’m not sure if I’m able to share more beyond what I already have.
