Correct the verification claims in the hardened-boot i.MX93 note

[jetm]

Problem

The published field note 2026-06-24-hardened-boot-imx93.mdx states in its Coverage table that LUKS2 /var, phase-2 TPM2 sealing, dm-verity, IMA/EVM and module signing are all Verified on avocado-imx93-frdm hardware. None of that holds.

• The implementing PRs are still open: meta-avocado #232 and #236.
• The hardware validation step has never been run.
• Avocado could not boot on this board at all on the BSP those PRs target. The 6.6.36 SPL stalls before Normal Boot on Rev1.2 silicon, from any medium; the board first booted after the meta-imx pin moved to 6.18.20. The note was published 2026-06-24; the board came up 2026-08-05.

The proxy column was wrong in the other direction: it named five harness assertions, of which three exist and only on the #232 branch (so they gate nothing on scarthgap), and two do not exist anywhere in the repo.

This matters because the page is public and Secure Boot is an open ask from several accounts.

Solution

Correct the verification status and leave the design content alone. The technical write-up is sound; only the claims about what has been proven were false. A status admonition near the top states plainly what is and is not verified and links both open PRs, so the page stays useful rather than reading as retracted.

Key changes

• Coverage table rebuilt: hardware column is Not yet run throughout; proxy column reports what the qemuarm64 run actually produced
• TestStatus targets and tested_against no longer claim the hardware target
• Verify it and Reproduce it reframed from results obtained into checks the hardware pass owes
• Two proxy findings the original omitted are recorded as open questions: TPM2 unseal fails on reboot and falls back to Argon2, and dm-verity is not active on that target
• The first-boot wedge is documented: a boot interrupted after the LUKS format but before the filesystem is created strands the device in emergency mode permanently, and re-provisioning does not clear it

Reviewer notes

The unseal-on-reboot failure is the open question worth attention. It is plausibly a QEMU artifact, since PCR 7 has no real Secure Boot state to measure under the OP-TEE fTPM, and equally plausibly the design sealing to a PCR that will not be stable. Only the hardware pass settles it, and that pass is starting now against a wrynose-based port of the two PRs.

npm run build exits 0. This page is not a draft, so the production build genuinely compiles it, and I checked the rendered banner and table in a browser.

[Copilot]

Pull request overview

This PR corrects overstated verification claims in the “hardened-boot i.MX93” field note, clearly separating what has been observed in the QEMU proxy run from what is still pending hardware validation on the i.MX93 FRDM.

Changes:

• Updates tested_against metadata and the TestStatus targets to remove the implied hardware validation.
• Adds a prominent verification-status caution banner and reframes “Verify it” / “Reproduce it” as hardware-pass checks rather than completed results.
• Rebuilds the coverage table and open-questions section to reflect current proxy findings and explicitly mark hardware status as “Not yet run”.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:183

• In the "Verify it" intro and expected output, the text reads awkwardly ("not output a board has already produced"), and the systemd-cryptenroll --list expectation is overly specific/inconsistent with the earlier section that describes Argon2id as slot 0 and TPM2 as slot 1. Consider tightening the intro sentence and making the expectation describe the condition (Argon2id slot removed; TPM2 slot present) without hard-coding a slot number.

These are the checks the hardware pass still has to run. The output below is what they should produce, not output a board has already produced. Run them on the board after boot:

```bash
# /var is LUKS2 and mounted from the mapped device
cryptsetup status /dev/mapper/var

[jetm]

The hardware pass this note was waiting on ran today, so the LUKS2 row is filled in - c10139a.

What the board showed. FRDM-IMX93 on the wrynose BSP (meta-avocado#271): /var is a LUKS2 container on /dev/mmcblk1p8, aes-xts-plain64, 512-bit, mounted from /dev/mapper/var, with dmsetup targets listing crypt v1.28.0. First boot ran open -> no filesystem -> create -> ready; a second boot exercised the unlock path and /var reopened with the same filesystem UUID across a reboot confirmed by a changed boot_id.

Three defects had to be fixed before any of that worked, and each was invisible on the proxy because avocado-qemuarm64 carries a machine override imx93 lacked: DM_CRYPT silently demoted to =m by kconfig, AVOCADO_VAR_PART_DEV unset so fstab pointed at the raw partition, and a key provider reading /var/private/var-key-secret - a file on the volume being unlocked that nothing in the tree creates.

Phase-2 TPM2 moves from "not yet run" to "not possible on this board yet", which is a different claim and I think the more useful one. There is no TPM on the FRDM-IMX93 to seal to - no discrete part (UM12181, and the schematic BOMs for the i.MX95 siblings), and the i.MX9 route to a TPM 2.0 interface is a firmware TPM on OP-TEE that optee-ftpm-init currently builds for avocado-qemuarm64 only. So the open question about the TPM2 slot reopening /var is now pinned from both sides: the proxy cannot show it for want of RPMB, the board cannot show it for want of a TPM.

The security-properties section needed the sharpest edit. It claimed two independent factors. On this board today there is one, and it is weaker than "passphrase" implies: the key derives from the SoC UID, which binds the volume to one board but is not a secret, since anyone who can read it from a running system can rederive it. Device binding is real and worth claiming; confidentiality against an attacker who has already had code execution on the device is not, and the note said otherwise.

Also adds a reproduce section - none of this is reachable without knowing that the stock image ships root login disabled (root:*:), that the board boots from eMMC by default so an SD image needs SW1[3:0] moved to 0011, and that the default flash task rewrites var.

npm run build passes, static files generated.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (5)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:294

• There are two top-level sections titled “## Reproduce it” (one around build/flash steps and one for adversarial tests). Duplicate headings create duplicate anchors and make the ToC ambiguous; rename one of them (e.g., the adversarial section) to a distinct heading.

## Reproduce it

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:236

• PR description says the coverage table’s hardware column is “Not yet run throughout”, but this table marks hardware as Verified for LUKS2 /var (and the frontmatter also claims validation on 2026-08-12). Either the PR description needs updating or the table/frontmatter should be adjusted so they match, because reviewers will otherwise read the change as contradicting the stated intent.

| Control        | `avocado-qemuarm64` (proxy)                     | `avocado-imx93-frdm` (hardware)                    |
| :------------- | :---------------------------------------------- | :------------------------------------------------- |
| LUKS2 `/var`   | Verified on first boot                          | **Verified**, first boot and reboot (2026-08-12)   |
| Phase-2 TPM2   | Enrollment verified; unseal on reboot **fails** | **Not possible on this board yet** - see below     |

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:45

• The caution admonition says “What is not verified: any of it on the i.MX93 FRDM board”, but later the page claims LUKS2 /var was validated on hardware (frontmatter tested_against, coverage table, and “The hardware pass (2026-08-12)”). This reads as self-contradictory and undermines the corrected verification messaging. Rephrase this paragraph to reflect that only LUKS2 /var has been verified on hardware so far, while the rest remains proxy-only/not yet run.

This issue also appears on line 233 of the same file.

What is not verified: any of it on the i.MX93 FRDM board. The implementation is still
in review ([meta-avocado #232](https://github.com/avocado-linux/meta-avocado/pull/232)
and [#236](https://github.com/avocado-linux/meta-avocado/pull/236) are open), and two
results from the proxy run are open questions rather than details: TPM2 unseal on
_reboot_ fails there and falls back to the Argon2 slot, and dm-verity is not active on

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:204

• This paragraph is still grammatically incorrect/ambiguous (“not output anything has produced yet”). It also mixes “output a board has produced” with “checks that should produce output” in one sentence. Consider rephrasing so it clearly distinguishes verified command output from expected output for not-yet-run checks.

This issue also appears on line 294 of the same file.

## Verify it

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:288

• The page gives conflicting guidance on whether a re-flash clears /var: earlier it says fwup -t complete rewrites the whole medium including var (line 199), but here it says re-provisioning doesn’t clear the wedge because fwup -t complete does not touch var. These two statements can’t both be true; please verify the actual fwup behavior and make the doc consistent so readers don’t brick devices based on incorrect recovery steps.

- **An interrupted first boot wedges the device permanently.** `cryptsetup-var.sh` only runs `mkfs.btrfs` in its first-boot branch. A first boot that dies after `luksFormat` but before `mkfs.btrfs` leaves a LUKS2 header with no filesystem inside, so every later boot takes the open-existing branch, never creates the filesystem, and drops to emergency forever. Re-provisioning does not clear it, because `fwup -t complete` does not touch the `var` partition; recovery means zeroing the LUKS header by hand. The fix is either to detect "header present, no filesystem on the opened mapper" and re-`mkfs`, or to make format-plus-mkfs atomic behind a completion marker.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:182

• There are now two sections titled “Reproduce it” (this one and another later in the note). Duplicate headings create ambiguous anchors and make the document harder to navigate; consider renaming this earlier section to reflect that it’s the build/flash steps.

## Reproduce it

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:208

• Minor wording/grammar: “output a board has produced” / “not output anything has produced yet” reads awkwardly. Rephrase so it’s clear what output is confirmed vs expected.

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:50

• The admonition contradicts the rest of the note: it says nothing is verified on i.MX93 hardware, but the frontmatter and Coverage table state LUKS2 /var was validated on avocado-imx93-frdm (2026-08-12). Update the admonition title/body so it accurately reflects partial hardware verification (LUKS2 only) and that the remaining controls are still proxy-only / design-only.

This issue also appears in the following locations of the same file:

• line 182
• line 208

What is verified, on `avocado-qemuarm64` standing in for the board: LUKS2 `/var`
formatted on first boot, and the two-phase enrollment landing an Argon2 recovery
keyslot alongside a TPM2 keyslot sealed to PCR 7.

What is not verified: any of it on the i.MX93 FRDM board. The implementation is still

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (4)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:49

• The admonition currently says “proxy only” and “What is not verified: any of it on the i.MX93 FRDM board,” but the page now documents hardware verification for LUKS2 /var (2026-08-12) and AHAB signed boot (2026-08-13) and the coverage table marks those as verified. This is internally inconsistent and may mislead readers skimming the banner.

What is verified, on `avocado-qemuarm64` standing in for the board: LUKS2 `/var`
formatted on first boot, and the two-phase enrollment landing an Argon2 recovery
keyslot alongside a TPM2 keyslot sealed to PCR 7.

What is not verified: any of it on the i.MX93 FRDM board. The implementation is still

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:208

• This sentence is hard to parse (“not output anything has produced yet”) and reads as contradictory with the rest of the section. Rephrase to clearly separate the LUKS2 commands (real output) from the other checks (expected output not yet validated on hardware).

## Verify it

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:10

• PR description says the hardware column is “Not yet run throughout,” but this note now claims hardware verification for LUKS2 /var (2026-08-12) and includes a signed-boot pass (2026-08-13). Please align the PR description with the content (or, if these hardware results shouldn’t ship yet, remove/adjust the new hardware-verified claims).

tested_against: 'Avocado 0.41.2, avocado-qemuarm64 (fTPM via QEMU). LUKS2 /var validated on avocado-imx93-frdm hardware 2026-08-12 (wrynose BSP, meta-avocado #271), first boot and reboot. Phase-2 TPM2, dm-verity and module signing NOT yet validated on that hardware; IMA/EVM is design only and not implemented in the layer.'

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:360

• There are now two top-level sections named “Reproduce it” (this one and the earlier build/flash section). Duplicate headings can create confusing navigation and collide on generated anchors/links. Consider renaming this section to describe its purpose (adversarial validation) while keeping the earlier “Reproduce it” for build steps.

## Reproduce it

Three adversarial tests, stated as predictions the hardware pass should confirm or break. None has been run on a board yet, and each one failing would say something specific about which control is not doing its job:

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (5)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:44

• This paragraph says nothing is verified on i.MX93 FRDM hardware, but later sections and the Coverage table claim LUKS2 /var (and signed boot) have been validated on hardware. Reword this to reflect what is verified vs still unverified on hardware, and keep the proxy-only caveats for the remaining open questions.

What is not verified: any of it on the i.MX93 FRDM board. The implementation is still
in review ([meta-avocado #232](https://github.com/avocado-linux/meta-avocado/pull/232)
and [#236](https://github.com/avocado-linux/meta-avocado/pull/236) are open), and two
results from the proxy run are open questions rather than details: TPM2 unseal on
_reboot_ fails there and falls back to the Argon2 slot, and dm-verity is not active on

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:208

• The second sentence reads ungrammatically (“not output anything has produced yet”). Rephrase so it’s clear these are expected outputs for checks that haven’t been demonstrated yet.

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:242

• The PR description says the hardware column is “Not yet run throughout” and that tested_against/TestStatus no longer claim the hardware target, but this doc now asserts multiple hardware validations (e.g., LUKS2 /var verified on 2026-08-12; signed boot verified on 2026-08-13/14). Please reconcile the PR description vs the updated claims so reviewers/readers have a consistent source of truth.

| Control        | `avocado-qemuarm64` (proxy)                     | `avocado-imx93-frdm` (hardware)                    |
| :------------- | :---------------------------------------------- | :------------------------------------------------- |
| LUKS2 `/var`   | Verified on first boot                          | **Verified**, first boot and reboot (2026-08-12)   |
| AHAB signed boot | No harness case exists                        | **Verified** on an open part - bootloader and OS container (2026-08-13), initramfs folded into the signed container (2026-08-14). See below |
| Phase-2 TPM2   | Enrollment verified; unseal on reboot **fails** | **Not possible on this board yet** - see below     |

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:32

• The admonition title says “proxy only”, but this note now includes verified i.MX93 hardware results (e.g., tested_against and the Coverage table). Update the title so it doesn’t contradict the rest of the page.

This issue also appears in the following locations of the same file:

• line 40
• line 238

:::caution Verification status: proxy only, the hardware pass is still open

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:419

• There are now two ## Reproduce it headings in this document (at lines 182 and 419), which will generate duplicate anchors/TOC entries in MDX. Rename one of them to keep heading IDs unique.

## Reproduce it

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (5)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:249

• The coverage table marks multiple controls as Verified on avocado-imx93-frdm hardware, which contradicts the PR description (hardware column should be "Not yet run" throughout). Please align the table with the stated intent.

| Control        | `avocado-qemuarm64` (proxy)                     | `avocado-imx93-frdm` (hardware)                    |
| :------------- | :---------------------------------------------- | :------------------------------------------------- |
| LUKS2 `/var`   | Verified on first boot                          | **Verified**, first boot and reboot (2026-08-12)   |
| AHAB signed boot | No harness case exists                        | **Verified** on an open part - bootloader and OS container (2026-08-13), initramfs folded into the signed container (2026-08-14). This exact board can no longer re-run this check - see below |
| Phase-2 TPM2   | Enrollment verified; unseal on reboot **fails** | **Verified** - PCR-7 keyslot enrolled via the OP-TEE fTPM on first boot (2026-08-19); reboot-survival of this specific TPM2 slot not yet independently re-tested on hardware. See below |

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:35

• This admonition says LUKS2 + TPM2 sealing are "verified on hardware" and references dated board passes, but the PR description says the hardware pass has not been run. Either the PR description or this admonition is out of date; if the goal is "correct the verification claims", this should not assert hardware verification.

:::caution Verification status: LUKS2 and TPM2 sealing verified on hardware; dm-verity, IMA/EVM and module signing are not
This note went out reading as a finished hardware result before any of it had run on a
board. LUKS2 `/var` and phase-2 OP-TEE fTPM sealing are now genuinely verified on
`avocado-imx93-frdm` hardware; the table near the end of this note reflects that.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:10

• The frontmatter tested_against now claims multiple avocado-imx93-frdm hardware validations (2026-08-12/19, meta-avocado #279), but the PR description states the hardware validation step has never been run and the implementing PRs are still open (#232/#236). Please reconcile by removing the hardware-validation claim here (or updating the PR description if the validations truly occurred).

This issue also appears in the following locations of the same file:

• line 32
• line 245

tested_against: 'Avocado 0.41.2, avocado-qemuarm64 (fTPM via QEMU). LUKS2 /var and phase-2 OP-TEE fTPM PCR-7 sealing both validated on avocado-imx93-frdm hardware (2026-08-12 and 2026-08-19, meta-avocado #279). dm-verity and module signing NOT yet validated on that hardware; IMA/EVM is design only and not implemented in the layer.'

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:70

• In "What it demonstrates", the TPM2 bullet still says phase 2 "kills the Argon2id slot", but the corrected "Phase-2 TPM2 enrollment" section below now says the Argon2id recovery slot is never killed. This is an internal inconsistency that will confuse readers.

- LUKS2 `/var` formatted on first boot by the initramfs, with no pre-provisioned key material shipped in the image
- Two-phase TPM2 enrollment: phase 1 uses a software Argon2id passphrase as a recovery baseline; phase 2 seals a new key to TPM2 PCR 7 (Secure Boot state) via `systemd-cryptenroll` and kills the Argon2id slot only after a `--token-only` unseal confirms the TPM path works
- dm-verity rootfs integrity gated on the `secureboot` DISTRO_FEATURE, with every rootfs block cryptographically verified on read
- IMA/EVM runtime appraisal - designed, not built. The intent is that the kernel refuses to open or execute a mutable file whose IMA signature does not verify, with EVM sealing the security xattrs and measurements logged to PCR 10. No kernel fragment, policy recipe, or `ima` gate exists in the layer today

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:215

• Grammar/clarity: "not output anything has produced yet" is hard to parse. Rephrase so it's clear these checks are expected output, not something already observed on a board.

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (5)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:402

• This paragraph says “Nothing seals to PCR 7 on an i.MX93 today.” but the very next section (“The fTPM hardware pass (2026-08-19)”) documents that PCR-7 sealing did run on the board. Rephrase this as time-scoped to the 2026-08-12 pass so the note doesn’t contradict itself.

**Phase-2 TPM2 remains unshown, and not for want of running it.** There is no TPM on this board to seal to. The FRDM-IMX93 has no discrete TPM (confirmed against UM12181 and, for its i.MX95 siblings, the schematic BOMs), and the i.MX9 route to a TPM 2.0 interface is a firmware TPM on OP-TEE, which `optee-ftpm-init` currently builds for `avocado-qemuarm64` only. Nothing seals to PCR 7 on an i.MX93 today. The board does have what that route needs - OP-TEE enabled, 32 GB eMMC so RPMB exists, and a `recovery` partition for the TEE store - so this is a porting task rather than a hardware limitation, and it needs no AHAB work. Worth knowing when reading NXP material: on i.MX, "TPM" in a datasheet or device tree usually means the **Timer/PWM Module** peripheral, not a trusted platform module.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:217

• This line says the TPM2/dm-verity/IMA/module-signing checks are “not output anything has produced yet”, but later the note includes real TPM2 hardware output (2026-08-19) and the coverage table marks TPM2 as verified. Rephrasing here will avoid confusing readers about which sections are verified vs still “expected”.

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:251

• The PR description says the hardware column should be “Not yet run” throughout and that TestStatus/tested_against should no longer claim the hardware target, but this table marks multiple controls as Verified on avocado-imx93-frdm hardware. Please reconcile the PR description vs the document content so they describe the same verification state (either update the PR description, or adjust these hardware claims back to “Not yet run”).

| Control        | `avocado-qemuarm64` (proxy)                     | `avocado-imx93-frdm` (hardware)                    |
| :------------- | :---------------------------------------------- | :------------------------------------------------- |
| LUKS2 `/var`   | Verified on first boot                          | **Verified**, first boot and reboot (2026-08-12)   |
| AHAB signed boot | No harness case exists                        | **Verified** on an open part - bootloader and OS container (2026-08-13), initramfs folded into the signed container (2026-08-14). This exact board can no longer re-run this check - see below |
| Phase-2 TPM2   | Enrollment verified; unseal on reboot **fails** | **Verified** - PCR-7 keyslot enrolled via the OP-TEE fTPM on first boot (2026-08-19); reboot-survival of this specific TPM2 slot not yet independently re-tested on hardware. See below |

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:32

• The admonition title ends with “are not”, which reads incomplete (not what?). Adding “yet verified” makes the title grammatically complete and matches the intent of the banner.

:::caution Verification status: LUKS2 and TPM2 sealing verified on hardware; dm-verity, IMA/EVM and module signing are not

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:10

• This frontmatter line currently bundles two dates in a way that can be read as if both LUKS2 and TPM2 sealing were validated on both 2026-08-12 and 2026-08-19. Clarifying which validation happened on which date will keep the summary accurate.

This issue also appears in the following locations of the same file:

• line 217
• line 402

tested_against: 'Avocado 0.41.2, avocado-qemuarm64 (fTPM via QEMU). LUKS2 /var and phase-2 OP-TEE fTPM PCR-7 sealing both validated on avocado-imx93-frdm hardware (2026-08-12 and 2026-08-19, meta-avocado #279). dm-verity and module signing NOT yet validated on that hardware; IMA/EVM is design only and not implemented in the layer.'

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:433

• This line says the recovery slot is argon2i, but the rest of the note consistently describes the recovery slot as Argon2id. Align the algorithm name here with the rest of the document (or update the other references if argon2i is actually what’s used).

Slot 0 stays `argon2i` - the recovery keyslot - and is never removed; see the corrected

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:405

• This paragraph says nothing seals to PCR 7 on i.MX93 "today", but the next section documents that the imx93 fTPM port landed and ran on 2026-08-19. Reword this section to be time-scoped to the 2026-08-12 pass (and avoid contradicting the 2026-08-19 results).

**Phase-2 TPM2 remains unshown, and not for want of running it.** There is no TPM on this board to seal to. The FRDM-IMX93 has no discrete TPM (confirmed against UM12181 and, for its i.MX95 siblings, the schematic BOMs), and the i.MX9 route to a TPM 2.0 interface is a firmware TPM on OP-TEE, which `optee-ftpm-init` currently builds for `avocado-qemuarm64` only. Nothing seals to PCR 7 on an i.MX93 today. The board does have what that route needs - OP-TEE enabled, 32 GB eMMC so RPMB exists, and a `recovery` partition for the TEE store - so this is a porting task rather than a hardware limitation, and it needs no AHAB work. Worth knowing when reading NXP material: on i.MX, "TPM" in a datasheet or device tree usually means the **Timer/PWM Module** peripheral, not a trusted platform module.

The intent still holds: both paths run the same recipes, kernel fragments and initramfs logic, and both seal to the same OP-TEE fTPM (`MACHINE_FEATURES += " optee-ftpm"` on `avocado-qemuarm64`, per `meta-avocado-qemu/conf/machine/avocado-qemuarm64.conf`) - what differs is the platform underneath it, QEMU `virt` against i.MX93 silicon. So a cheap proxy gate should guard the expensive hardware path. It is an intent rather than a seal until the cases merge and the board pass runs.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:218

• The "Verify it" intro sentence is ungrammatical and now overstates what has not yet been produced (later sections include real TPM2 and LUKS2 hardware-pass output). Rephrase to clearly distinguish transcripts from expected output. Also, the immediately-following "Expected" note about the Argon2id slot being gone appears to conflict with the earlier section that keeps the recovery slot.

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

[jetm]

Pushed one more commit (3251a7c), rebased onto the current tip of this branch.

The caution block and the "dm-verity: Not active on this target" coverage row already in this PR say the feature is unverified on this board. Three passages still described it as built, which is a stronger claim than the evidence supports:

• the capability table said a hash tree is computed at build time and verified on every block read
• the "what it demonstrates" list said every rootfs block is cryptographically verified
• the threat-model paragraph asserted an offline patch is caught before the patched code executes

Nothing in meta-avocado generates a hash tree, signs a roothash, or opens a verity device. The only artifact is dm-verity.cfg, which sets CONFIG_DM_VERITY=y and then disables CONFIG_PKCS7_MESSAGE_PARSER, so a signed roothash could not be verified even if a tree existed.

Those three now use the same idiom this note already applies to IMA/EVM two rows down ("Designed only", "nothing implements it in the layer yet"), so a reader can tell the two unimplemented controls apart from the one that is built. The threat-model paragraph splits for the same reason: PCR-7 sealing is verified on this board and gets its own sentence, while dm-verity, IMA/EVM and module signing are stated as intent with a pointer to the coverage table.

scripts/checks.sh passes (prettier + build, exit 0).

The same claims appear in the customer-facing security pages and are corrected separately in #491, since those are undated present-tense product docs rather than a dated note.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (5)

Previously missed (2) — in code that hasn't changed since the last review.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:405

• The 2026-08-12 hardware-pass section says phase-2 TPM2 is “unshown” and that nothing seals to PCR 7 on i.MX93 “today”, but the very next section documents the 2026-08-19 fTPM hardware pass where PCR-7 enrollment did run on avocado-imx93-frdm. Reword this paragraph to make the timeline explicit and avoid contradicting the later section.

This issue also appears in the following locations of the same file:

• line 481
• line 482
• line 492

**Phase-2 TPM2 remains unshown, and not for want of running it.** There is no TPM on this board to seal to. The FRDM-IMX93 has no discrete TPM (confirmed against UM12181 and, for its i.MX95 siblings, the schematic BOMs), and the i.MX9 route to a TPM 2.0 interface is a firmware TPM on OP-TEE, which `optee-ftpm-init` currently builds for `avocado-qemuarm64` only. Nothing seals to PCR 7 on an i.MX93 today. The board does have what that route needs - OP-TEE enabled, 32 GB eMMC so RPMB exists, and a `recovery` partition for the TEE store - so this is a porting task rather than a hardware limitation, and it needs no AHAB work. Worth knowing when reading NXP material: on i.MX, "TPM" in a datasheet or device tree usually means the **Timer/PWM Module** peripheral, not a trusted platform module.

The intent still holds: both paths run the same recipes, kernel fragments and initramfs logic, and both seal to the same OP-TEE fTPM (`MACHINE_FEATURES += " optee-ftpm"` on `avocado-qemuarm64`, per `meta-avocado-qemu/conf/machine/avocado-qemuarm64.conf`) - what differs is the platform underneath it, QEMU `virt` against i.MX93 silicon. So a cheap proxy gate should guard the expensive hardware path. It is an intent rather than a seal until the cases merge and the board pass runs.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:218

• This sentence is grammatically awkward (“not output anything has produced yet”) and makes it hard to tell what is real board output vs expected output. Rephrase for clarity.

Everything under LUKS2 below is output a board has produced. The TPM2, dm-verity, IMA/EVM and module-signing checks are what they should produce, not output anything has produced yet - see the coverage table.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:481

• This bullet still discusses luksKillSlot/slot-0 removal and monitoring for the kill, but the earlier “Phase-2 TPM2 enrollment” section states the Argon2id recovery slot is intentionally never killed and that the luksKillSlot choreography never runs on real boards. The open-question should be updated to match the current, verified behavior.

- **`luksKillSlot` guard.** The `|| true` on slot 0 removal is intentional but means a failed kill leaves both slots active. A monitoring check after enrollment should confirm slot 0 is gone; the current implementation does not warn if the kill is skipped.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:492

• This adversarial test reads like something the current hardware pass can run, but earlier sections say IMA/EVM is not implemented in the layer today (so this check can’t currently succeed). Clarify that it’s a future/conditional test.

- Copy a stock binary into `/var/tmp` and run it. IMA appraisal should deny the exec for want of a valid `security.ima` signature, while the same binary in its signed rootfs location runs normally.

src/field-notes/2026-06-24-hardened-boot-imx93.mdx:482

• This sentence says IMA is “gated on ima”, but the coverage section above says no ima gate exists in the layer today. Rephrase to avoid implying there is a currently-functional ima feature gate.

- **IMA/EVM raises a labeling and update cost.** Every appraised file must carry a valid `security.ima` signature, so the build signs the rootfs and shipped mutable content, and every OS update re-signs and shifts the measured hashes. That makes the attestation server's known-good list an ongoing ops dependency. First boot also runs roughly 5-15% slower while IMA labels and measures, which is why IMA is gated on `ima` rather than always on.