Signed FIT Configurations: Prevent Mixing a Trusted Kernel with the Wrong Device Tree

Authenticate the selected FIT configuration and its required image hashes when the approved unit is a kernel/device-tree combination. Individually signed components can establish who signed each component while leaving the relationship between them unprotected. A release review must therefore ask both “are these bytes approved?” and “is this combination approved?”

This guide pins U-Boot v2024.10 and its FIT mechanisms. It assumes an already protected verifier and control device tree; it does not establish a ROM trust chain, change keys or configure a production board. All fixture outcomes below are proposed qualification criteria, not executed boot results.

1. Define the approved combinations explicitly

Create a release table with one row per supported board configuration: kernel identity, device-tree identity, optional initramfs and additional firmware. Use exact artifact hashes and the FIT node names that reference them. A component’s descriptive label is not a release identity.

For a hypothetical two-board product, approve kernel K1 with DTB D1 for board A and kernel K2 with DTB D2 for board B. State whether K1/D2 is forbidden, unsupported or independently qualified. Do not leave the answer to whether the mixed pair happens to reach a login prompt.

U-Boot’s signed-configuration documentation explains the mix-and-match limitation of image-only signatures and the configuration-signature mechanism that includes referenced image hashes. That is the technical boundary this review exercises.

2. Inspect the generated signature coverage

Review the generated FIT, not only its source template. Record the selected configuration node, the image-role properties it contains, and the image/hash nodes included by the signing process. Confirm that every component relied on by the boot contract is covered.

The v2024.10 host implementation uses an explicit sign-images list when present. Otherwise its default role list is kernel, fdt and script, with missing default entries permitted. Do not assume that adding another role, such as ramdisk or loadables, automatically extends the intended coverage.

Make this a build-output assertion: each required role resolves to the expected node, its payload hash is present, and its relationship to the selected configuration is inside the reviewed signature boundary. If a signing-template change omits a role, fail the release check before a board test can hide it.

When verifying on a host, also verify the actual payload bytes against the image hashes. A valid signature over configuration metadata does not establish that a separately inspected payload still matches that metadata.

3. Verify enforcement in the consuming loader

A signature node in a FIT is not evidence that the loader requires it. Inspect the final verifier build and the control FDT it actually consumes. Keep that trusted control tree separate from the device tree delivered to the operating system as a payload.

In v2024.10’s required-key verifier, configuration requirements come from the control FDT’s key policy. A build with no required configuration keys is not equivalent to a policy that rejects every unsigned selected configuration. Record the effective required-key and multiple-key policy without changing it during this audit.

Trace the real boot path to its configuration-verification call. A successful check in a host utility or another loader stage cannot prove this caller enforces the same boundary. Preserve the exact loader binary, control-tree hash and generated FIT with the test evidence.

4. Use a valid-component versus valid-combination matrix

Controlled fixture	What it isolates	Required interpretation
Approved K1/D1 configuration, unchanged	Working positive control	Pass the signature gate and reach the defined safe test endpoint
K1 and D2 remain valid individual components; relationship is altered without authorized configuration signing	Combination binding	Reject before handing control to the unintended combination
Configuration unchanged; D1 payload bytes modified	Payload-to-signed-hash binding	Reject the payload mismatch
New unsigned configuration referencing otherwise approved components	Mandatory selected-configuration authentication	Reject under the intended required-conf policy
Unmodified, genuinely signed board-B configuration selected on board A	Board selection and compatibility policy	Signature can pass; independent board policy must prevent an unsuitable handoff

The last row is essential. Signing a set of configurations does not determine which one is appropriate for the current board. A legitimate signer can approve several configurations, and the selection mechanism still needs a trustworthy board-to-configuration rule.

Keep the mixed-component fixture structurally valid and loadable in the controlled environment. A missing node or malformed container rejected by the parser does not demonstrate that configuration authentication rejected a validly structured unauthorized relationship.

5. Observe selection, verification and handoff separately

Capture the selected configuration name and resolved component identities before interpreting a signature message. Then identify the verification decision and the last stage reached. A failure after the kernel begins may be a device-tree incompatibility rather than a successful authentication barrier.

Use recoverable lab targets with preserved original media and inert workloads. Do not test a mismatched tree on live actuators or a board where incorrect peripheral configuration could cause damage. Prefer a harmless fixture that distinguishes identities without depending on electrical misuse.

For each negative case, repeat the unchanged positive control under the same loader and policy. This catches unrelated failures such as damaged storage, missing trust metadata or an incorrect load address. Keep these controls focused on relationship enforcement; broader cryptographic and parser testing remains a separate qualification task.

6. Preserve the boundary after verification

Inventory any later device-tree edits, overlays and boot-argument construction before the operating-system handoff. A verified input tree can be changed by trusted loader code afterward. That may be necessary for memory discovery or per-unit data, but its allowed changes need their own policy.

Also keep rollback acceptance separate. A complete older signed configuration can remain cryptographically valid even when current product policy forbids it. Configuration binding prevents an unauthorized combination; it does not automatically provide monotonic release enforcement.

Close the release with a combination receipt

Deliver the approved combination table, generated coverage report, effective verifier policy and paired test outcomes. If a new board variant adds a payload role, repeat the coverage review rather than copying the previous “signed FIT” label.

The hypothetical K1/D2 pair is rejected for the intended reason only when the tested path authenticates the selected relationship and verifies its payloads. A separate selection check must still choose the right approved relationship for the board that is actually booting.