cryptsetup-var: report /var encryption posture to the KV store

[jetm]

Problem

cryptsetup-var.sh fails open in two places, both deliberately. ensure_tpm2_enroll() keeps the volume encrypted under Argon2id if the TPM2 enroll fails, and open_var() falls back to the Argon2id key file if the TPM2 unseal fails. That is the right call — a legitimate PCR 7 change (a Secure Boot policy update, a key rotation) must not lock a device out of its own /var.

The cost of that choice is silence. A device whose PCR 7 moved keeps booting on the recovery slot indefinitely, and from outside it is indistinguishable from a correctly sealed one: a later luksDump shows that a TPM2 token exists, not that it was the thing that worked. At fleet scale that means a storage-security control can lapse across a whole deployment with no signal anywhere.

Solution

Record the one fact nothing can reconstruct afterwards — which keyslot actually opened the volume — and publish it, plus the token's presence and whether /var really came up through the mapper, into the U-Boot KV store that peridiod already reads.

The /var-through-the-mapper check is re-done in userspace rather than trusted from the initrd on purpose: opening the container says nothing about what fstab then mounted. That exact mismatch was a real defect on this board when AVOCADO_VAR_PART_DEV was unset — container opened in the initrd, /var mounted from the raw partition underneath it.

Key changes

• cryptsetup-var.sh gains write_posture(), which drops three facts in /run/avocado-var-posture. Best-effort by construction: posture must never be the reason /var fails to open.
• New avocado-posture-publish.sh + .service (rootfs-only) read that file, re-check the mount, and publish avocado_var_unlock, avocado_var_tpm2_token, avocado_var_encrypted.
• New ${PN}-posture package so the publisher stays out of the initrd.

Two design points worth calling out for review:

Why /run and not the KV store directly from the initrd. Neither fw_setenv nor the fw_env.config it needs exists in this initramfs (see the recipe's own RDEPENDS note), and avocado-uboot-env.service generates that config in the real root. /run is the same early tmpfs the key file already depends on, and systemd carries it across the switch-root.

Why publish on change only. The KV backend is a U-Boot environment block on the boot medium and its own docs expect infrequent writes. Re-writing three keys every boot would be steady flash wear for no new information, and a change is the interesting event — the first enroll, or the day a device silently drops to the recovery slot.

The unit orders After=avocado-uboot-env.service without requiring it: that unit lives in meta-avocado-nxp while this ships in the shared layer, so it has to stay valid on a machine with no such generator. systemd ignores After= on a non-existent unit, and the script exits 0 when the tooling is absent.

Verification

Not built and not run on hardware — the build hosts were in use. What was verified, by stubbing fw_printenv/fw_setenv/findmnt:

Case	Result
Healthy first boot	publishes all three keys
Identical second boot	writes nothing (write-on-change holds)
tpm2 -> argon2id regression	flips only that key, warns naming PCR 7
/var on the raw partition	reports avocado_var_encrypted=no
No posture file (unencrypted image)	exits 0 with a diagnostic
No libubootenv tools	exits 0 with a diagnostic

Separately confirmed write_posture cannot abort the unlock: it survives a failing token probe under set -e (which is why it uses if rather than && — the && form is the footgun here) and survives an unwritable target. shellcheck --shell=sh is clean on both scripts.

Reviewer notes

Three things I could not verify without a build, listed so they get eyes rather than assumed:

1. The package split depends on PACKAGES order. FILES:${PN} globs the whole ${libexecdir}/cryptsetup-var/ directory and so also matches the publisher; PACKAGES =+ prepends, so ${PN}-posture claims it first and it stays out of the initrd. I documented that in the recipe, but documenting is not testing — worth confirming the publisher is genuinely absent from the initramfs after a build.
2. libubootenv and util-linux-findmnt resolving as RDEPENDS.
3. The transport stops at the KV store. peridiod reads that store, but I did not verify it forwards arbitrary avocado_* keys to Peridio cloud, or that anything cloud-side surfaces them. So this makes posture durable and queryable on-device; the fleet-visible half is a further step.

Scope stayed at LUKS/TPM deliberately. No AHAB lifecycle or fuse-state reporting here — I have no verified userspace path to read the ELE lifecycle and would have been guessing at one.

[mobileoverlord]

Merged into wrynose via #316 (rebased, commits preserved). Closing as included.