When using a TPM to provide integrity measurements for a system via SRTM, the trusted computing base is reduced to only the TPM and CRTM. The CRTM is a component of the BIOS (specifically the bootblock) which executes first and allows the TPM to hash the remaining contents of the BIOS, in effect making it so that even compromised firmware cannot break the chain of trust. It is intended to be read-only and is stored alongside the BIOS. If it is not read-only, then it cannot provide integrity.
Typically, the chain of trust goes like so (where the CRTM and TPM are trusted):
The CRTM sends the hash of the BIOS itself to the TPM.
The BIOS sends the hash of the option ROMs, MBR, and bootloader to the TPM.
The bootloader sends a hash of the kernel and boot parameters to the TPM.
The kernel is executed, and it verifies the integrity of userspace executables.
Each earlier stage verifies subsequent stages, all the way to userspace. When the kernel is up, the TPM will only "unseal" itself and reveal a secret value if all of the hashes it has gotten thus far are correct. A compromised system will not be able to successfully unseal the TPM and the secret value not be revealed. The end result is that, if the CRTM is trusted, everything will have been verified and need not be trusted, from the BIOS to the kernel to userspace. All of this relies on the assumption that the CRTM and TPM cannot be modified. However, the potential for implementation issues was highlighted in the section Implementation Specific Attacks on the ITL blog.
How can one verify that a specific vendor's CRTM is read-only in hardware?