FIT Verification in SPL: Check the Small Loader Build Instead of Assuming U-Boot Proper Covers It
Audit SPL as its own verifier binary. A main U-Boot build that supports FIT signatures does not establish that SPL authenticates the next image before executing it. The useful evidence is a chain from resolved SPL configuration through linked code and consumed key policy to an observed SPL rejection.
This procedure pins U-Boot v2024.10 and its simple/full FIT-loading paths. It is an audit and qualification plan, not instructions to change security settings, program fuses or provision keys. No U-Boot build or target test was run for this article.
1. Identify the early loader that actually runs
Record the deployed SPL image hash, build revision, board configuration and packaging method. Confirm how the ROM or preceding stage selects that image. Keep the main U-Boot binary hash in a separate field.
Locate the actual FIT load entry point. Is the board using the simple loader, the full loader, a vendor-specific implementation or a non-FIT path? A source repository containing the desired verification function does not mean the deployed binary reaches it.
Capture the final resolved configuration, not only the defconfig fragment. Build defaults, dependencies and later configuration changes can make the final values differ from the intended input. Preserve these files with the release instead of reconstructing them from memory after a failure.
2. Compare main-stage and SPL configuration evidence
The v2024.10 Kconfig defines SPL_FIT_SIGNATURE separately. Its visible dependencies include SPL driver-model support and either the simple or full SPL FIT loader. It selects supporting symbols including FIT signature support, SPL FIT, cryptographic/hash support, image-signing information and full FIT structural checking.
Its RSA-related SPL options are implied, rather than all being unconditionally selected. Audit the resolved cryptographic provider for the algorithm actually used. Do not treat an implied default as proof that every required implementation survived configuration resolution.
| Evidence layer | Main U-Boot | SPL-specific question |
|---|---|---|
| FIT signature option | Record final FIT_SIGNATURE | Record final SPL_FIT_SIGNATURE independently |
| Loader selection | Identify consuming boot path | Which SPL_LOAD_FIT or SPL_LOAD_FIT_FULL path is compiled and used? |
| Algorithm support | Identify required algorithm/provider | Is the matching early-stage provider actually resolved and linked? |
| Structural checks | Record relevant FIT checking options | Confirm SPL’s resolved structural-check configuration |
| Control tree | Hash main-stage policy input | Which separate control-tree bytes does SPL consume? |
The table is an evidence checklist, not a complete dependency recipe for every board. In particular, enabling a top-level symbol cannot substitute for a trusted key policy or a qualified boot route.
3. Follow the build into the final executable
The tagged boot Makefile uses stage-prefixed FIT signature selection for the signature verifier and FDT-region objects. Check the SPL build’s map, symbol information or disassembly, as appropriate to its optimization and link settings.
Look for evidence that the intended verifier path and cryptographic implementation are retained in SPL, rather than only in U-Boot proper or a host utility. Keep the final packaged SPL tied to the executable used for the inspection.
Absence of a familiar symbol name is not conclusive when optimization inlines or removes names; presence of a symbol is not proof that execution reaches it. Resolve ambiguity with the build’s debug information and call path. Report an unresolved linkage question instead of converting a grep result into a security claim.
4. Trace configuration and payload verification separately
In v2024.10’s simple SPL path, configuration verification is conditional on the SPL signature option. Its image-loading path also calls the image verifier on the payload bytes when stage-specific signature support is enabled. The full path sets the verification flag for its generic FIT-loading calls under SPL signature support.
Map the selected board path to those checks. Record error propagation and whether failure can lead to a different image, medium or caller. An expected recovery route may be legitimate, but it must not make the original invalid image appear accepted.
Then inspect SPL’s consumed control FDT. The FIT signature reference describes required image/configuration key policy. Including a public key or verifier code without the intended enforcement policy is not equivalent to requiring an authorized signature.
5. Separate payload integrity from mandatory authentication
On an approved recoverable test setup, retain an unchanged valid FIT as the positive control. Prepare a structurally valid integrity fixture whose payload differs from the approved bytes while its expected hash remains unchanged. Use only test artifacts and an inert next-stage endpoint. Rejection of this case demonstrates payload-integrity checking; hashing alone could produce that result.
Add a separate authentication fixture for the intended required-configuration policy: change the payload and its image hash coherently, but leave the required configuration signature unchanged. Keep the container structurally valid. The image hash should now be self-consistent, while the authenticated configuration no longer matches. Require rejection attributable to SPL’s required configuration-signature path before handoff.
Require the unchanged positive control to reach the intended next-stage marker under the same loader and key policy. Preserve all three generated-artifact identities and distinguish the integrity result from the mandatory-authentication result.
If SPL loads the altered next stage and U-Boot proper later rejects another image, the result does not demonstrate SPL enforcement. If the altered fixture fails during media reading or FIT parsing, it has not isolated the intended cryptographic check. Repair the fixture or environment before drawing a conclusion.
No production storage should be overwritten for this audit. Use the board’s approved development loading and restoration procedure, preserve original media, and ensure test execution cannot control live equipment.
6. Interpret configuration asymmetry correctly
A hypothetical release archive contains a main U-Boot configuration showing signature support, but the packaged SPL came from an older build. The main-stage evidence is genuine and still irrelevant to the missing early-stage proof.
The correct response is to reconcile binary provenance, final SPL configuration and observed behavior. Do not simply copy the main-stage option value into the checklist or assume that one successful signed boot proves rejection of unauthorized input.
Release evidence to retain
Close with both binary hashes, resolved configurations, loader-path identification, stage-specific link evidence, consumed control-tree identity and separate positive-control, integrity and required-signature observations. Record what remains outside the result: the preceding stage’s trust, other loaders, physical fault resistance and production provisioning.
Repeat this audit when switching loader paths, changing cryptographic providers or reducing SPL size. A space optimization that changes the early executable deserves the same enforcement evidence as the original release.
