Measured boot¶
Runtime attestation answers "what has this host executed since it booted?" Measured boot answers the question underneath it: what did it boot?
Without it, a host that booted a different kernel — or the same kernel with a different command line, or with Secure Boot switched off — can still produce an honest IMA log and a valid quote. Everything it ran since boot is measured correctly. The lie is one layer down, in the part nothing was looking at.
What is in the quote now¶
The TPM quote covers PCR 0–10, not PCR 10 alone. The signed digest therefore binds the boot chain — firmware, bootloader, kernel command line, kernel and initramfs — alongside the runtime measurement log.
The agent additionally sends its live PCR 0–9 values and the raw TCG2 event log
(/sys/kernel/security/tpm0/binary_bios_measurements). Neither is trusted.
The verifier replays the event log to reproduce PCR 0–9 for itself and then
recomputes SHA256(pcr0‖…‖pcr10) against the signature. A reported value is
used only where the log cannot produce one, and it still has to survive that
recomputation. A host that sends a flattering event log fails the digest.
Read once, at startup
The agent reads the PCRs and the event log before it accepts any connection, and caches them. They are static after boot, and reading a file inside the quote/log-read window would itself be a measured event under a broad IMA policy — it would inject an entry between "quote taken" and "log read". This is the same rule that keeps package lookups off the quote path.
Which PCRs are enforced, and which are not¶
Four are enforced:
| PCR | What it covers |
|---|---|
| 4 | The bootloader, and what it loaded |
| 7 | The Secure Boot state |
| 8 | The kernel command line |
| 9 | The kernel and the initramfs |
PCR 0–3, 5 and 6 are quoted and bound by the signature, but not compared against an approved value. They cover firmware and platform configuration, and they move on a BIOS update, a firmware setting, or a change of hardware — none of which is a compromise. Enforcing them would produce an alarm for every vendor firmware release, and an alarm that fires for routine maintenance is one an operator learns to dismiss.
The four that are enforced are the ones an attacker has to touch to boot something else and keep it.
Where the approved values come from¶
The first time a host attests genuinely, the verifier records its current
enforced PCRs as that host's approved boot state, attributed to
daemon:first-sight. Nothing is compared on that first cycle — there is
nothing to compare against — and every cycle after it is.
What daemon:first-sight means, and what it does not
It means: this is what the host was booting the first time we saw it, and it has not changed since. It does not mean anybody looked at those values and judged them good. If a host was already compromised at enrolment, first-sight records the compromise as the baseline — the same trust-on-first-use limit that enrollment itself carries.
To make it a decision rather than an observation, run op approve-boot
yourself after confirming what the host booted.
The values are covered by the daemon's signature, and baseline
verify-signatures re-derives the signed payload from the stored rows:
An edit made directly in the database — changing what counts as a good boot without going through an approval — is caught there and the command exits non-zero:
boot host lab155 — TAMPERED: the stored PCR values don't match the signed
payload. Somebody changed what counts as a good boot for this host without
re-approving it.
Approving a new boot state¶
A kernel update, a cmdline edit or a firmware change moves the enforced values. That is expected, and it is a decision:
etminan-verifier op approve-boot --host web-01 \
--reason "kernel 6.12.9 rolled out, change CHG-4471"
This is a four-eyes action where dual control is enabled: whoever can approve a boot state single-handed can boot a host into something else and then bless it, after which every later attestation reports Genuine and quiet. See Dual control.
OS groups — one approval for a fleet¶
Hosts running the same distribution, release and architecture boot the same
kernel and produce the same enforced values. The agent reports its own
(distro, release, arch) triple, read from /etc/os-release and the native
package tool, so nobody maintains a list that goes stale on a dist-upgrade.
etminan-verifier op approve-boot --from-host web-01 \
--reason "golden boot state for debian/trixie/amd64 after the 6.12.9 rollout"
takes web-01's current state as the approved state for its whole group
(admin only). --clear yes drops a group policy again.
The triple is a selector, not a judgement: it says which policy applies, never whether the host passes. A host that lies about its group is not thereby trusted — it is enforced against another group's values, which is a mismatch, not a pass. The one escape it could buy — claiming a group with no policy, to fall through into permissive first-sight recording — is closed on the verifier side: a host's group is pinned the first time it attests genuinely, and a later change fails closed.
What you will see when it goes wrong¶
The boot state changed. Raised as boot-policy-mismatch:
this host booted something other than its approved boot state. […] These values came out of the TPM-signed quote, so the host did boot this — the question is whether the change was intended. PCR 4 is the bootloader, 7 the Secure Boot state, 8 the kernel command line, 9 the kernel and initramfs.
Confirm the change was yours, then op approve-boot --host <h>.
The OS group changed. Also boot-policy-mismatch:
this host now reports the OS group 'X' but was pinned to 'Y' when it first attested. The group is self-reported and is NOT covered by the quote signature, so this is either a dist-upgrade or an attempt to claim a group with no boot state to be enforced against.
op approve-boot --host <h> re-pins the group along with the boot state.
No boot data at all. Some virtual firmware exposes no TCG2 event log. Such a host sends neither PCR values nor a log, nothing is enforced, and the check reduces to exactly its previous PCR 10-only behaviour. Absence is not treated as a finding — a missing log is a property of the platform, not evidence against the host — but it does mean measured boot is not protecting that host, and you should know which of your hosts are in that state.
The honest limits¶
Secure Boot has to be on for PCR 7 to mean anything. PCR 7 records the Secure Boot state, and on a machine with Secure Boot disabled that state is "disabled" — recorded faithfully, approved as the golden value, and stable forever after. Enforcement then proves the host still has Secure Boot off. The mechanism works; the platform is not offering anything to check.
First sight is not review. See the warning above. A fleet where every host
carries daemon:first-sight has continuity, not verification.
A virtual TPM measures a virtual boot. On many hypervisors PCRs that a physical platform populates are left at the empty value. Golden values calibrated on such a guest encode that hypervisor's idea of a boot; they do not transfer to bare metal, and a group that mixes the two will not settle. See Virtualized hosts.