Measured Boot and the Chain of Trust From Firmware to Kernel

A signature check on a boot component answers one question: is this component the one the platform owner approved. It does not answer the question an auditor usually asks, which is what the machine actually executed, in what order, with what configuration. A component can be approved and still be an older version with a known defect. A component can be approved and then have data handed to it that changes its behaviour. Verifying each stage in isolation produces a boolean, and a boolean is not a record.

Measured boot produces a record. Each stage, before transferring control to the next, computes a cryptographic hash of what it is about to execute and extends that hash into a hardware register that cannot be rewound. The result is a value that depends on the entire sequence of stages and their inputs, and a remote party who knows the expected sequence can recompute it and compare. Nothing is prevented; everything is recorded.

The PCR extend operation

The register is a Platform Configuration Register inside a Trusted Platform Module. It holds a digest-sized value, 32 bytes for SHA-256, and it has exactly one mutating operation: extend. Extending does not write the new measurement into the register. It computes

PCR_new = H(PCR_old || measurement)

where H is the hash algorithm associated with the register and measurement is the digest being recorded. The concatenation is of the current register value followed by the new digest, and the result replaces the register.

The consequence of this definition is that the register’s value depends on the order and content of every measurement since reset, and that no measurement can be removed or reordered without changing the final value. It is also the reason a PCR cannot be set to an arbitrary value: the only way to reach a particular value is to extend the exact sequence that produces it. A TPM does support a reset of the PCR bank at platform reset, and it supports clearing the whole TPM under specific authorization, but neither is available to software during a boot.

Extending is deliberately cheap and does not require the TPM to store anything per measurement. The TPM performs one hash and one internal write, and the record of what was measured lives outside the TPM, in a log that the measuring software maintains. The log is the evidence; the PCR is the commitment to it. A verifier receives both, replays the log’s digests through the extend operation, and checks that the replay reproduces the PCR values it was given. A log that has been altered produces a mismatch, because the alteration changes the replay result.

What gets measured, in what order

On a UEFI platform the sequence is fixed by the firmware profile. The first measurement covers the firmware’s own code, taken by a component in the boot block that runs before the rest of the firmware. Subsequent measurements cover firmware configuration, the secure boot policy variables, the components loaded by the firmware, and the boot target.

The registers are partitioned by convention rather than by hardware. In the PC client profile, register 0 holds the measurement of the code that begins the chain, register 1 holds firmware configuration, registers 2 and 3 hold option ROM code and its configuration data, register 4 holds the boot manager’s code, whether that is a master boot record or the EFI application the firmware launches, register 5 holds the partition table or the equivalent boot structure, and register 7 holds the secure boot policy variables. Registers 8 and 9 are used by the operating system’s boot loader: register 8 typically covers the loader’s configuration and the kernel command line, register 9 the kernel image and the initramfs. Register 10 holds the operating system’s runtime measurements of executed programs, and registers 11 through 15 are available to the operating system for its own use. The registers above 15 are allocated by convention to debug and application use, with one reserved for a dynamic root of trust measurement. The partitioning is a convention that verifiers rely on; the TPM itself treats all registers alike.

The split matters because a verifier usually wants to evaluate one stage at a time. A policy might require that the firmware measurements in registers 0 through 7 match a known-good set, and separately that the kernel measurement in register 9 matches a set of approved kernels. If everything were extended into one register, the value would change on any firmware update and no policy could distinguish a legitimate firmware update from a kernel change.

The kernel command line is measured alongside the kernel, which is not obvious but is necessary. The command line carries parameters that change what the kernel does: which root device to mount, whether to disable a security feature, which module to load. A kernel that measures its own image but not its parameters leaves a gap through which the boot can be steered without changing any measured digest.

Measurement versus enforcement

Measured boot and secure boot are complementary and often confused. Secure boot enforces: the firmware refuses to execute a boot component whose signature does not verify against a key in its allowed database, and the refusal is immediate and total. Measured boot records: the firmware extends a digest and proceeds regardless.

The combination is what makes attestation useful. Secure boot guarantees that the components which ran were signed by someone the platform trusts. Measurement guarantees that the specific signed components which ran are known, and that no unsigned component was inserted between them. Neither alone is sufficient for a remote party: enforcement without measurement cannot tell which approved component ran, and measurement without enforcement can report an accurate record of a compromised boot.

There is an important limitation on the enforcement side. Secure boot’s trust anchors live in firmware variables that are writable by an administrator with physical access, and the firmware’s verification covers the components it loads, not the data those components subsequently consume. A signed boot loader that loads an unsigned kernel because its configuration permits it produces a measured record showing exactly that, and the record is only meaningful to a verifier that knows the policy the loader was configured with.

Attestation and its boundaries

An attestation is a signed statement from the TPM that a set of PCR values is current, bound to a nonce the verifier chose. The nonce defeats replay: a signed quote from an earlier boot cannot be presented as evidence about this one. The signature is made by an attestation key that the TPM holds, and the verifier’s trust in that key is established separately, typically through a certificate chain rooted in the TPM vendor and endorsed at manufacture.

The verifier then replays the measurement log and compares the result to the quoted PCRs, and compares the individual measurements to a policy. A machine whose firmware, boot loader, kernel, and command line all match the policy produces a quote the verifier accepts. A machine whose kernel was replaced produces a quote that fails at the kernel measurement.

What the quote does not cover is anything after the measurement. A kernel that was measured correctly can be compromised at runtime, and the PCR values remain valid for the boot that was measured. Extending the chain into user space requires the operating system to keep measuring: the integrity measurement architecture in the Linux kernel measures executables as they are mapped for execution, and appends those measurements to a runtime PCR, which lets a verifier see which programs ran after boot. That measurement is subject to the same limitation: it records what was executed, and a process that has already been measured can be subverted afterwards.

The other boundary is the log’s completeness. A verifier can only detect a measurement that was omitted if the omission changes the PCR, and it does not: extending fewer measurements produces a different PCR value, which the verifier will reject against a policy that expects the full sequence. The failure is therefore detectable, but only if the policy is specific about which registers and which sequence it expects. A policy that accepts any value in a register accepts an attacker who simply did not measure.

Where it fails in practice

The most common practical problem is that firmware updates change the measurements, so a policy pinned to exact values rejects a machine that has been patched. Verifiers handle this by maintaining sets of approved values per firmware version, which is an operational burden that grows with the number of models in a fleet.

The second is that the boot loader’s measurement of the kernel often covers the compressed image, not the decompressed kernel. A verifier must know which form was measured to compare correctly, and the two forms have different digests. The kernel’s own measurement of its loaded modules happens later and lands in a different register, so a policy that requires module measurement must account for the register split described above.

The third is that some platforms measure the same component more than once, because the firmware loads it and then the boot manager loads it again, and each load extends the register. The resulting value is correct for the sequence that actually occurred, and a verifier that assumed a single measurement will compute a different value. The measurement log is the only reliable way to know which sequence occurred.

A fourth is the TPM’s own availability. A platform with a disabled or absent TPM produces no measurements, and the boot proceeds. A policy that requires attestation must therefore treat the absence of a quote as a failure, not as an unknown, or the mechanism is trivially bypassed by disabling the device.

The measurements begin with the firmware, whose first instruction is at the reset vector described in the reset vector and the first instruction. The stage that measures the kernel is the boot loader, whose structure is covered in why boot loaders are split into stages. And the transition after which firmware services stop being available, which also fixes the point at which firmware-held measurements are complete, is the ExitBootServices call discussed in how firmware describes physical memory.