External FIT Data and Signed Metadata: Verify the Payload the Loader Actually Uses
Trace a signed FIT configuration through its image hash to the exact external bytes the loader reads. External storage does not inherently remove authentication, but a configuration signature alone is not a whole-file checksum or proof that every location field is authenticated.
This guide pins U-Boot v2024.10. Its main address worksheet follows the memory-resident FIT helper; simple SPL differences are called out separately. Encryption, decompression and board post-processing need additional input/output tracing. No U-Boot build, signature operation or target boot was executed.
1. Preserve metadata and payload as one release object
Retain the complete packaged artifact, the metadata block and the selected image identities. A copy limited to the device-tree metadata may omit the very bytes needed for boot validation.
The tagged host implementation can extract embedded image data, replace it with locator and size properties, then write the payload separately in the output layout. Inspect the final output rather than assuming the input source describes its final byte positions.
Record the external-data convention chosen by the packager, total delivered length and the loader’s FIT base. Keep storage-medium offsets separate from offsets inside the artifact. “Offset 4096” is incomplete until its origin is stated.
2. Resolve each locator with the correct origin
In fit_image_get_data_and_size(), data-position is relative to the FIT base. Otherwise, data-offset is added to the metadata total rounded up to four bytes. External length comes from data-size; without either locator, the helper uses embedded data.
For the worksheet, let F be the metadata total, A its four-byte-aligned value, P a data-position value, O a data-offset value, and S the external size. The resulting artifact-relative span starts at P or A + O and extends for S bytes.
| Hypothetical metadata | Artifact-relative span | Audit question |
|---|---|---|
| F = 1,001; O = 20; S = 80 | 1,024 through 1,104, end excluded | Does the delivered object include the entire span? |
| P = 2,048; S = 80 | 2,048 through 2,128, end excluded | Was P mistaken for a physical flash address? |
| Both locator properties present | Scoped helper prefers data-position | Reject ambiguous packaging in the release policy |
Check every addition against the actual available bytes and integer limits in your offline inspector. Require nonambiguous, approved ranges. Those are proposed release checks; do not infer a complete bounds guarantee from this pointer-returning helper.
3. Understand what the configuration signature excludes
The configuration verifier excludes data, data-size, data-position and data-offset from its signed regions. The signing implementation uses matching exclusions and includes the selected image hash nodes.
This distinction matters when diagnosing a changed layout. Do not label the locator properties authenticated merely because their image node participates in a signed configuration. Likewise, a signature passing after a locator change is not by itself evidence of a broken signature check.
The intended authentication chain requires the relevant image digest to be bound to an authorized configuration, then requires the actual loaded image bytes to satisfy that digest. Review both links with required-key policy enabled in the intended build.
4. Verify the fetched bytes, not a convenient copy
The memory-resident image verifier resolves data and size through the helper before passing them to image verification. Confirm that your inspection and test harness use that same span. Hashing an original source binary is insufficient if the loader resolves a different region.
For simple SPL, external reads include transport alignment handling before verification of the selected payload length. Its external-data base also passes through a board alignment hook. Do not automatically reuse the memory-resident base calculation for every SPL integration.
Retain the reader implementation, block-size convention, board hook and observed returned length. A valid digest calculation over a host file cannot prove that a truncated target read supplied all required bytes.
5. Use controls with distinct conclusions
| Proposed fixture | Required interpretation |
|---|---|
| Complete approved artifact | Positive control validates intended configuration and payload |
| External payload altered; original image digest retained | Payload integrity must fail on the resolved bytes |
| Payload and digest changed coherently; required configuration signature retained | Required configuration authentication must reject the changed binding |
| Identical payload moved with corresponding locator update | Content authentication can remain valid; location is not independently authorized by that signature |
| Artifact truncated before the external span ends | Packaging/read gate rejects safely; no acceptance from leftover buffer contents |
| Metadata size changes while relative offset is kept | Recompute the resolved span; inspect any shifted lookup |
Run malformed-layout cases first in a bounds-checked host or instrumented reader environment. Later target tests require preserved originals, disposable media and a verified recovery path. Do not use arbitrary invalid addresses on a production device.
Classify failures as packaging, source-read, image-hash or required-signature failures. A parser rejecting a malformed test does not demonstrate that the required signature path ran.
Hypothetical metadata-only copy
A fictional release pipeline copies exactly F bytes into a transport package because F looks like the FIT size. The metadata remains readable, but the external image span ends later. A metadata inspection succeeds while the complete-artifact range check fails.
The release decision is to repair and requalify packaging, retaining the frozen original. Do not suppress a payload check or treat successful metadata parsing as a usable boot image.
6. Keep a source-to-use map
The final receipt should name each selected image, locator origin, resolved span, delivered length, authenticated digest binding and reader path. Record any transformation after verification and its separately qualified limits.
Repeat the map when changing packaging alignment, metadata layout, loading stage or storage reader. The useful assurance is that the authorized content is the content actually consumed within approved bounds, not simply that a FIT signature appears somewhere in the artifact.
