tpm-enrol: move NV cert index off OEM-occupied 0x01800001 → 0x01800100
The Dell 820 kept "finding a cert" and bypassing enrolment despite repeated BIOS TPM clears. tpm2_nvreadpublic revealed 0x01800001 on that hardware is a FIRMWARE platform index (platformcreate|policydelete|writelocked, 70 bytes — not our cert; siblings at 0x01800003/4 + 0x01810000). platformcreate survives TPM2_Clear and policydelete needs the platform's secret policy, so it's permanent and unusable by us — the blind check false-positived on it, and enrolment could never write there anyway. Same class of bug as the EK-handle collision. Move the NV cert index default 0x01800001 -> 0x01800100 (free on the 820, owner range, overridable via rd.dot1x.nvindex): cmdline (extract-artifacts.sh), fleet-enrol -nvindex, the dracut hooks, bench scripts, CLAUDE.md invariant #1, and design/SSP docs. The signing-key handle (0x81000100) is unchanged. Harden WriteNVCert: refuse a platformcreate index with a clear "pick a free owner index via rd.dot1x.nvindex" error instead of a confusing undefine failure. Regression simtest/TestWriteNVCertRefusesPlatformIndex; NV roundtrip + ReadNVCert tests moved to 0x01800100. All go tests + packer validate pass.
This commit is contained in:
@@ -20,7 +20,7 @@ These are consequences of the CLAUDE.md invariants, not preferences:
|
||||
stateless and buffers only in RAM (best-effort).
|
||||
2. **Identity from the TPM, never baked.** No per-host state in any artifact
|
||||
(invariant #1). The agent derives identity at runtime from the **TPM-held
|
||||
cert** (key `0x81000100`, cert NV `0x01800001`) — the same identity used for
|
||||
cert** (key `0x81000100`, cert NV `0x01800100`) — the same identity used for
|
||||
802.1X EAP-TLS and the NVMe hostnqn. No enrollment token in the image.
|
||||
3. **Pull-based control, no inbound surface.** The boot LAN is locked down and
|
||||
segmented; we do not open an always-on inbound control port on hosts. Hosts
|
||||
|
||||
Reference in New Issue
Block a user