Secure-Boot Acceptance with Debug Builds: Prove Diagnostic Features Cannot Relax Trust
Compare diagnostic and release builds by the behavior each configuration difference changes, not by their labels. A logging-only difference, an authorization-policy difference and a fault-hardening difference need different evidence. Passing the same ordinary bad-signature test does not establish that two binaries retain the same hardening.
This guide pins MCUboot v2.2.0’s Zephyr fault-injection-hardening profiles as a concrete comparison mechanism. It does not claim that selecting “debug” automatically changes a profile, or that debug builds are inherently insecure. No build, hardware fault experiment or target acceptance test was executed.
1. Freeze the two artifacts being compared
Record both final bootloader hashes, source revisions, compiler/linker versions, resolved configurations and trusted public-policy identities. Include any downstream patches and generated source. Keep the application used as a fixture identical where the comparison requires it.
Generate a complete configuration difference, then classify each item. Do not discard a setting because its name looks like instrumentation: dependencies and wrapper behavior may affect the verification path.
| Delta class | Examples to investigate | Evidence needed |
|---|---|---|
| Observation | Logging verbosity, trace output | Same acceptance/refusal decisions, bounded diagnostic effects |
| Authorization | Required verification, trust identity or accepted format | Explicit policy approval and signer-specific controls |
| Hardening | FIH profile, failure handling, delay provider | Resolved mechanism and binary evidence, plus separately scoped qualification |
| Resource behavior | Stack, allocation, timing and watchdog interaction | Target resource evidence under the intended workload |
A difference can belong to more than one class. Instrumentation that changes memory layout may also change a timing or resource result, even when the intended signature decision is unchanged.
2. Resolve the actual FIH profile
The profile choice distinguishes OFF, LOW, MEDIUM and HIGH. LOW adds global failure handling and control-flow checks; MEDIUM adds doubled-variable mechanisms; HIGH additionally introduces randomized delays requiring an entropy source.
The mapping header converts the resolved Zephyr choice into MCUboot macros. Compare those emitted macros, not merely a menu screenshot or a source configuration fragment.
Use the profile names as implementation selectors, not numerical security ratings. The words “high” and “medium” do not establish a measured resistance threshold or guarantee immunity to a physical fault mechanism.
3. Inspect the retained mechanisms
The hardening header implements conditional feature selection and the hardened call/return wrappers. Its CFI mechanism checks expected call accounting; the documentation explicitly distinguishes it from general ROP or JOP protection.
Review sensitive validation call sites and their paired return paths. A downstream early return introduced for diagnostics must preserve the selected wrapper contract. Do not assume that a function containing a cryptographic check automatically integrates all surrounding hardening.
The implementation source supplies conditional counter operations and the global failure loop. Connect those source paths to the linked binary through appropriate build/debug evidence. Optimization can change symbol visibility, so an absent symbol name alone is not a conclusive result.
If randomized delays are part of the intended profile, identify the actual delay/entropy integration and its failure contract. A selected macro does not establish that the platform supplies the intended entropy or that target timing remains acceptable.
4. Keep normal refusal tests and fault qualification separate
Run ordinary functional acceptance controls on both binaries through the same boot route. Use an approved positive image, a structurally valid unauthorized-signer image, an unsigned image and a covered-byte integrity failure. Record the precise refusal stage.
These controls establish the observed policy decisions in ordinary execution. They do not establish equivalence under instruction skips, corrupted state or other physical faults. That requires a separately authorized, platform-specific assessment with an explicit fault model.
| Observed comparison | Permitted conclusion |
|---|---|
| Both binaries reject the unauthorized signer | That ordinary fixture is rejected in both tested paths |
| Same normal results, different FIH profiles | Functional observations match; hardening equivalence remains unproven |
| Diagnostic build accepts a required-negative fixture | Release comparison fails; identify the changed acceptance path |
| Profile matches but compiler/link behavior differs | Source intent matches; binary and target evidence still need review |
| More detailed logs, unchanged acceptance | Observed diagnostic change is bounded to the tested cases |
Do not run destructive fault experiments on production devices to fill an evidence gap. Keep approved inert fixtures, recoverable development equipment and the organization’s security-testing authority separate from this review plan.
5. Review failure behavior with diagnostics unavailable
Test the approved behavior when a diagnostic destination is missing, full or slow. Logging must not convert a verification failure into success or cause an unintended alternate boot policy. Resource exhaustion must retain an explicit failed result.
Keep trace data bounded and nonsecret. Avoid printing private material or raw trust-provider buffers merely to explain why a signature did not verify. Use public identifiers and stage markers.
Record which artifact produced each log. A trace from the diagnostic build cannot be relabeled as release-binary evidence, even when both come from the same source commit.
Hypothetical profile drift
A fictional team’s diagnostic and release binaries both reject an unauthorized image. Their semantic configuration comparison nevertheless finds different hardening profiles. The test report initially concludes that secure-boot behavior is identical.
The corrected report narrows that conclusion to the ordinary acceptance fixtures and opens the profile difference for review. The team must reconcile its approved release policy and gather the appropriate binary/target evidence; it cannot infer fault resistance from those passing functional tests.
6. Release a delta receipt
Keep each changed setting, its semantic class, approving requirement, linked evidence and applicable fixture results. Mark hardware fault resistance, entropy quality and timing as unqualified unless actual supporting work exists.
The deliverable is an artifact-specific diagnostic/release comparison with clear limits. It helps ensure that adding observability does not silently change trust, without treating all development features as dangerous or claiming that one profile name proves complete protection.
