tpmmgr: device certificate is stored in TPM NV as PEM and written unchunked, leaving ~108 bytes of headroom

[eriknordmark]

Summary

writeDeviceCert() stores the device certificate in TPM NV as PEM, and
writes it with a single un-chunked TPM2_NV_Write. On an Infineon SLB9665 the
per-write ceiling (TPM_PT_NV_BUFFER_MAX) is 768 bytes and the stored
certificate is 660, so there are 108 bytes of headroom before the write
starts failing — and that failure is currently silent and permanent (#6344).

Storing DER instead of PEM recovers ~33% immediately: the same certificate is 446
bytes in DER.

Detail

pkg/pillar/cmd/tpmmgr/tpmmgr.go:

deviceCertBytes, err := os.ReadFile(types.DeviceCertName)   // PEM
...
tpm2.NVDefineSpace(rw, tpm2.HandleOwner, etpm.TpmDeviceCertHdl,
	etpm.EmptyPassword, etpm.EmptyPassword, nil,
	tpm2.AttrOwnerWrite|tpm2.AttrOwnerRead,
	uint16(len(deviceCertBytes)))
...
tpm2.NVWrite(rw, tpm2.HandleOwner, etpm.TpmDeviceCertHdl,
	etpm.EmptyPassword, deviceCertBytes, 0)

go-tpm's NVWrite issues one TPM2_NV_Write with the whole payload; it does
not chunk. (Its NVReadEx counterpart does chunk, querying
TPM_PT_NV_BUFFER_MAX first — so reads are already correct.)

Measured on an EVE device with an Infineon SLB9665:

	Value
TPM_PT_NV_BUFFER_MAX (per-write ceiling)	0x300 = 768
TPM_PT_NV_INDEX_MAX (per-index ceiling)	0x680 = 1664
NV index 0x1500000 actual size	660
Same certificate encoded as DER	446

The TCG PC Client Platform TPM Profile sets the minimum NV_BUFFER_MAX at 512,
so a conforming part could be tighter than the 660 bytes EVE writes today. Worth
checking tpm2 getcap properties-fixed across the qualified platform list.

Why the headroom matters

Any addition to the certificate template consumes it. Concretely, adding a
device-specific serialNumber attribute to the subject — a change worth making
for other reasons, and only ~90 bytes of DER — takes the stored PEM to roughly
786 bytes. That is over the 768-byte ceiling, so NVDefineSpace succeeds (786 <
1664) and NVWrite then fails, triggering #6344.

Suggested fix

1. Store DER, not PEM. TCG's "TPM 2.0 Keys for Device Identity and
   Attestation" §7.3.3 recommends exactly this for LDevID/LAK certificates in NV:
   "A certificate chain SHOULD be stored as X.509 DER-encoded certificates, as
   this is the smallest form and requires no conversion for use by networked
   applications." (It is a SHOULD, inside a section that is RECOMMENDED as a
   whole; the MUST form is §7.3.2, which governs only OEM-provisioned IDevID/IAK
   chains. The binding constraint for EVE is the measured TPM_PT_NV_BUFFER_MAX,
   not the spec.) Accept either encoding on read so existing devices keep
   working.
2. Chunk the write against TPM_PT_NV_BUFFER_MAX, mirroring what NVReadEx
   already does for reads. Without this, nothing larger than one buffer can ever
   be stored even in DER — which also blocks storing a certificate chain, where
   a leaf plus one issuing CA runs about 1150 bytes in DER (under the 1664-byte
   index limit, over the 768-byte write limit).

Two adjacent observations from the same NV dump, worth folding in if these
indices are ever revised:

• All five EVE NV indices use a SHA-1 nameAlg, where the TPM vendor's own
  indices use SHA-256. EVE never chooses this — NVDefineSpace is called with
  nil for the policy and the default applies — so it is an artifact rather than
  a decision.
• The indices are ownerwrite|ownerread with an empty auth value and no policy,
  so anything with owner access can rewrite the device-certificate backup. That
  is consistent with its documented role as a backup rather than an anchor, but
  it is worth being explicit about if that role ever changes.

[eriknordmark]

Worth escalating the framing of this one: "108 bytes of headroom" is specific to
the part I measured. The TPM 2.0 library specification guarantees no headroom at
all.

TPM 2.0 Library Part 2 defines the TPM2B_MAX_NV_BUFFER operand as
buffer[size]{:MAX_NV_BUFFER_SIZE} with the note "MAX_NV_BUFFER_SIZE is
TPM-dependent". There is no floor in the library specification. The 512-byte
minimum I quoted comes from the TCG PC Client Platform TPM Profile, which is
one platform profile among several — and EVE targets ARM and embedded platforms
where a PC Client TPM profile is not necessarily what the part implements.

So for a device with an arbitrary TPM 2.0 compliant TPM, EVE's current
660-byte single TPM2_NV_Write is not "close to a limit"; it is unsafe by
construction. A conforming part reporting TPM_PT_NV_BUFFER_MAX of, say, 512
would fail the device-certificate backup on every new install today — and per
the linked issue, fail it silently and permanently.

The same caveat applies to the other ceiling: TPM_PT_NV_INDEX_MAX ≥ 1600 is
also a PC Client PTP requirement, not a library-spec guarantee.

This argues for making both suggested fixes non-optional rather than
nice-to-have, and for a third:

3. Feature-detect rather than assume. Query TPM_PT_NV_BUFFER_MAX and
   TPM_PT_NV_INDEX_MAX at provisioning time, size and chunk accordingly, and
   log the values so field data exists on what EVE actually encounters. go-tpm
   already does exactly this query inside NVReadEx; the write path just needs
   the same treatment.

If it would help, the measured values from an Infineon SLB9665 are
TPM_PT_NV_BUFFER_MAX = 0x300 (768) and TPM_PT_NV_INDEX_MAX = 0x680 (1664),
with the device certificate occupying 660 of them.