Authenticating Firmware Before Decompression: Bound Work on Untrusted Input
Authenticate the representation consumed by the decoder when the selected boot format supports it, and still bound decoding resources. An authorized compressed stream can be malformed or too large for the approved memory layout. Authentication and decoder safety answer different questions.
This guide pins U-Boot v2024.10’s simple-SPL FIT gzip path, with the intended required-signature policy and no board post-processing transformation. Full FIT loading, LZMA, encrypted content and downstream hooks need separate traces. No compressed fixture, bootloader build or hardware test was executed.
1. Draw the actual processing order
In the tagged simple-SPL path, enabled configuration verification occurs before image loading. The payload path calls image verification before a possible board post-processing hook and gzip expansion. Gzip receives CONFIG_SYS_BOOTM_LEN as its output-capacity argument.
Those checks are configuration-dependent. Establish the final SPL options, linked functions, required-key policy and executed path. A main U-Boot verification setting or successful host signature inspection does not prove that this SPL binary authenticates decoder input.
The FIT signature reference distinguishes required signatures from image hashes. The compressed payload’s expected digest must be bound to the intended authorization policy; a self-consistent hash by itself is not that authorization.
2. Identify every operation before authentication
Even a verify-before-decompress design must acquire bytes and parse enough metadata to find the verification input. Inventory those earlier reads, lengths, allocations and address decisions. They require their own bounds before trust is established.
Record the exact input span supplied to hashing and the exact span supplied to the decoder. If a board hook changes the pointer, length or bytes between them, the no-transformation assumption has failed. Review that hook’s trusted transformation contract rather than silently treating the output as the same verified object.
RFC 9124’s decompression use case recognizes compressed execution images and associated load-time metadata. It does not prescribe one universal implementation order for every boot format. Keep the article’s ordering claim limited to the pinned caller.
3. Budget simultaneous memory, not compressed file size
Create an allocation timeline for retained input, decompressed destination, decoder workspace, verification scratch, loader state and other live images. The peak is the largest sum of simultaneously live allocations, with each actual region counted once.
| Budget item | Evidence to obtain | Common mistake |
|---|---|---|
| Compressed source | Actual acquired span, padding and lifetime | Counting only payload bytes while retaining a larger read buffer |
| Decompressed destination | Approved mapped range and accepted output limit | Assuming a small archive implies a small output |
| Decoder workspace | Allocator/provider requirements and failure paths | Omitting internal allocations |
| Other live state | Loader, verifier, stack and concurrent images | Adding unrelated peaks or missing real overlap |
| Reserved memory | Linker/platform ownership map | Calling all physically present RAM available |
If input and output overlap, require explicit support from the selected decoder and caller. Do not assume in-place expansion is safe because a small sample worked. Distinguish addressability, lifetime and cache requirements from the byte budget.
4. Treat the output limit as one guard
The gzip wrapper processes the gzip header before invoking its inflate helper. Passing a destination limit therefore does not by itself demonstrate safe handling of every malformed header, input length or internal allocation.
Review input bounds, output bounds and workspace failures individually. A compressed-stream length from metadata must be checked against the bytes actually available. Keep the approved output range separate from any size claim made inside the compressed representation.
Likewise, an output-byte ceiling is not a measured CPU-time bound. Establish an acceptable target boot duration and the product’s recovery behavior if decoding cannot complete. Watchdog servicing may prevent a reset without proving that the work finishes within the required time.
5. Use two different negative-test families
| Proposed fixture | Stage it should exercise | Required observation |
|---|---|---|
| Approved compressed positive image | Complete path | Verified input expands to the approved output and handoff |
| Changed compressed bytes with unchanged trusted digest | Payload integrity | Rejection before decoder entry |
| Coherent payload/digest change without required authorized signature | Authentication | Required-signature rejection before decoder entry |
| Authorized malformed compressed test stream | Decoder robustness | Bounded failure without executing partial output |
| Authorized stream exceeding approved output capacity | Resource limit | Controlled rejection without writing beyond the approved destination |
| Injected workspace allocation failure | Resource cleanup | Failure propagates without stale acceptance or leaked owned resources |
Use only approved synthetic artifacts and test-signing arrangements. A damaged unsigned stream rejected before decompression cannot establish decoder robustness. Conversely, successful parsing of an authorized stream does not prove unauthorized streams are kept out.
Begin with isolated host/instrumented tests and disposable buffers. Target qualification needs preserved artifacts, recoverable development devices and inert handoff targets. This article reports no execution of those tests.
Hypothetical compressed-size surprise
A fictional release fits its download budget, but its expanded image overlaps a reserved loader region. The signature is valid and the compressed file is smaller than the previous release. Neither fact satisfies the destination-memory gate.
The release should remain blocked until the output layout and resource budget are corrected and qualified. Raising a generic decompression limit without reconciling the memory map would hide the boundary rather than resolve it.
6. Retain ordering and resource evidence together
Deliver the exact SPL binary, verification policy, decoder version, input/output identities, allocation timeline and stage-specific fixture results. Include any board post-processing, omitted algorithm paths and untested resource failures.
Recheck when packaging, compression settings, workspace provider or memory layout changes. The acceptance result is an authenticated decoder input and bounded processing on the intended platform, not a broad claim that signed compressed firmware is automatically safe.
