Boot-Time Image Size and Address Bounds: Validate Metadata Before Loading
Qualify the destination range before the bootloader copies an image, and authenticate the resulting execution image before handoff. Those are separate gates. A valid signature does not make an arbitrary load address safe, while an address inside RAM does not authorize the bytes stored there.
This guide pins MCUboot v2.2.0, ordinary unencrypted and uncompressed RAM-load mode, and a single platform-defined executable RAM region. Multiple-image overlap checks, alternate memory mappings and downstream ports need additional review. The proposed cases have not been executed against MCUboot or hardware.
1. Identify the actual pre-authentication boundary
The tagged loader copies a RAM-load candidate before calling slot authentication. Thus bounded parsing and destination checks must already protect the copy operation. “The image is signed” cannot justify trusting its address fields before that verification completes.
Record the active build mode, selected slot, flash abstraction, RAM mapping and final linked functions. Confirm that the production-intended binary follows the reviewed branch; a source function that is not linked into the image is not evidence of a runtime guard.
Keep two review questions separate: what untrusted metadata can influence before authentication, and what code can execute after successful authentication? The first includes lengths, offsets and destination decisions. The second includes trust policy and controlled handoff.
2. Define an approved destination window
The RAM-loading design requires platform executable-RAM boundaries and distinguishes storage location from execution placement. Obtain those boundaries from the actual linker/platform configuration and hardware memory map.
Identify the bootloader’s own text, stack, working buffers, retained diagnostics and other reserved regions. An executable window must exclude memory that the copy must not overwrite. If usable space has holes, do not describe the whole enclosing address range as available.
Use R for the allowed start and L for its length, with an end-exclusive interval. Establish that R + L is representable in the implementation’s address domain. This is a platform configuration precondition, not a property that a candidate image may redefine.
3. Account for the full copied image
In boot_read_image_size(), the computed total includes TLV data as well as header and payload. It checks protected-size agreement and the expected TLV information headers. Therefore payload size alone is not the RAM-copy length.
Keep four quantities in the audit: available source bytes, declared payload size, authenticated span and total copied span. They answer different questions. The signature records may be outside the ordinary hashed span while still occupying destination RAM.
Use a bounds-checked offline inspector to map these quantities from a preserved artifact. Never allocate or seek solely from an unchecked metadata length. Record a missing or inconsistent value as a rejected inspection, rather than substituting a convenient default.
4. Trace the exact destination predicate
The RAM-load implementation requires the RAM-load flag, obtains D from the header and S from the total-image calculation, rejects D below R, rejects overflow in D + S, and rejects an end beyond R + L before copying.
For the scoped single-window review, express the intended acceptance as: D is at least R; D + S is representable; and D + S is at most the allowed end. Passing this range gate does not mean that all image-format or authentication gates pass.
| Proposed boundary case | Range-gate expectation | Protected concern |
|---|---|---|
| Destination at allowed start; complete span fits | Range may pass; other gates remain | Positive placement control |
| Destination one byte below start | Reject before destination copy | Memory preceding the executable window |
| Copied span ends exactly at allowed end | Range may pass | End-exclusive boundary |
| Copied span ends one byte beyond | Reject before destination copy | Following reserved memory |
| Destination-plus-size arithmetic overflows | Reject before destination copy | Wrapped address interpretation |
| Payload fits but complete image does not | Reject using complete copied span | TLV/header overhead omitted from sizing |
Also include absent RAM-load flag, truncated source and inconsistent TLV sizes. Attribute each rejection to the actual stage. A source-read failure cannot substitute for evidence that the destination predicate is active.
5. Observe rejection without damaging the only copy
Use an instrumented flash abstraction or controlled test build first. Record requested read length, destination interval and whether any destination write occurred. Avoid dumping payloads or secrets. Keep a known-good image as the positive control.
The scoped loader can call its source-slot removal path after RAM loading fails. Preserve original artifacts and use disposable, recoverable test storage; do not run malformed candidates on the only production or recovery image. A failed boot is not automatically a harmless read-only test.
For later hardware qualification, obtain the product’s approved recovery procedure and verify it beforehand. Inspect protected-memory guards and handoff status, not merely the final console message. A parser rejection, range rejection and signature rejection support different conclusions.
Hypothetical metadata-overhead failure
A fictional image has a 3,900-byte payload and a 4,096-byte approved destination window. Its header and TLV material increase the complete copied span to 4,200 bytes. A payload-only capacity check says it fits, but the correct copy-range review rejects it.
The response is to reconcile the approved image/layout budget. Do not enlarge the executable window into a reserved region just to make the image load. These invented sizes illustrate accounting only and are not a device memory map.
6. Preserve a boundary-specific release receipt
Retain the binary identity, executable window, source-area map, complete-span calculation, positive control and each observed failure stage. Include remaining limitations for compression, encryption, multiple images and platform address translation.
Recheck the receipt when metadata grows or a linker, platform, boot mode or loader revision changes. The acceptance outcome is bounded pre-authentication handling followed by authorized execution, each demonstrated on the intended implementation.
