I am trying to find out how the TPM performs an integrity measurement on a system. It is well-documented in the TPM specification how it seals the data it has measured in the PCRs and how it is updated. But that which I can't find explained is how the TPM actually performs the integrity measurements that it is sealing in the first place. To know if the system is in a given state or not it has to measure it, but how does it do that? And what is it that it actually measures? Most papers seem to gloss over this, and I get the feeling that ready-for-storage-in-PCR-data just appears out of the blue.
There's basically two way of doing this;
SRTM takes place at system boot. The first thing booting up - normally the BIOS boot block - which is the Core Root of Trust for Measurements (CRTM) - will measure the BIOS and send the value (hash) to the TPM (within Platform Configurations Register 0 - PCR 0) before passing execution to it. Then the BIOS measure the next thing in the boot chain and again send the value to the TPM, same for the boot loaders, etc. It's important to understand that while the TPM collects those measurements, it does not take action on them - actually, it can't. The value of those measurements can only be seen with the seal()/unseal()/quote()/etc operations. See TrustedGrub.
DRTM is very different as it's something happening while the system is running. Intel implementation is called Trusted Execution Technology (TXT) while AMD use the name Secure Virtual Machine (SVM). The goal of DRTM is to create a trusted environment from an untrusted state. In reality, it creates a secure/clean state and will report (measurement) on a piece of code someone wants to execute (aka Measured Launched Environement (MLE)). See Tboot.
Without going into details, Intel's DRTM works by calling a set of new CPU instructions (SMX) which tells the CPU and the chipset to perform a very specific set of tasks (GETSEC) which ensure nothing else then a special code can run, i.e. SINIT Authenticated Code Module (ACM). This part includes disabling all but one CPU and blocking/stopping everything currently running: all other processes, interrupts and I/O (via IOMMU, e.g. to avoid DMA attacks). Then, all CPU rejoin in a clean state - anything executed before is discarded. At this point the signature of this special code (SINIT ACM) gets validated and its identity (hash) is sent to the TPM (PCR 17). Afterwards, execution is passed to the ACM which measure the MLE and sends the measurement to the TPM (PCR 18). Finally, execution is passed to the MLE.
Now - just like SRTM - someone could use unseal() to reveal a secret which is only available if the trusted MLE is loaded, i.e. the correct PCR values are stored in the TPM. Consequently, the MLE can deduce the trusted code is loaded and nothing else, e.g. no need to trust the BIOS/OS.
UPDATED - I feel the answer is not quite complete without this part:
The security of those mechanisms relies on the fact that PCRs values cannot be set (or forged) but only extended (TPM_Extend). This means whenever a measurement is sent to a TPM, the hash of the concatenation of the current value of the PCR and the new measurement is stored (i.e. new_value = Hash(old_value || new_measurement)). Obviously, there's a beginning to all of this:
Hope this helps,
The TPM main specification is meant to be platform-independent. That is why no details about what is actually measured during startup are contained, because obviously the components differ from platform to platform. If you are interested in what is measured during the boot of a PC, you should take a look at section 1.3 (Overview of Measurement Process) of the TCG PC Client Specific Implementation Specification for Conventional BIOS.
Details on how the measurements are processed and stored in the PCRs can be found in the TPM Main Specification. Part 1, section 4.4 (Platform Configuration Register (PCR)) might be a good place to start.
I would also recommend taking a look at the TCG Architecture Overview to get the big picture, this is not directly related to your question, however.