MCUboot Downgrade Prevention Options: Check Which Update Modes Enforce the Intended Policy

Approve downgrade prevention from the compiled update path and comparison operands, not from an option name. MCUboot has software comparisons against installed image metadata and hardware-backed counter validation with a separate platform interface. Their availability, equality behavior and revert handling are not interchangeable.

This review pins MCUboot v2.2.0 and its Zephyr configuration mapping. It does not certify a board’s counter storage or recommend that historical release for deployment without later-fix review. No counters were provisioned, no options changed, and no update tests were executed.

1. Resolve the public option into implementation code

Record the final update mode, resolved Zephyr options, generated MCUboot macros and actual bootloader binary hash. The tagged Kconfig excludes the software downgrade option for direct-XIP. Its software security-counter variant is constrained to the move, scratch and offset swap modes.

The configuration mapping translates the Zephyr hardware downgrade option into MCUBOOT_HW_ROLLBACK_PROT. Keep both names in the evidence so a menu screenshot cannot be confused with the macro actually compiling validation code.

Then identify which function compares which values and when it runs. Menu visibility alone is insufficient to approve an unexamined mode, including RAM-load paths with different image selection behavior.

2. Reconcile documentation with the pinned implementation

The v2.2.0 design text describes software downgrade prevention as overwrite-only. However, the same tag’s Kconfig and loader include software checks for the named swap modes. Some comments also describe stricter version ordering than the implementation’s less-than comparison.

For this article, the tagged loader code determines the scoped behavior below. Preserve this discrepancy in the release review; do not mix a documentation sentence from one revision with assumptions about another implementation.

Mode and option	Compared value	Scoped behavior to verify
Overwrite plus software prevention	Secondary versus primary image version	Older candidate rejected when the primary header magic is not the erased-pattern value; equality is not rejected by this comparison
Move/scratch/offset plus software version comparison	Secondary versus primary version	TEST and PERM entry paths apply the check; REVERT does not pass through that same gate
Named swap modes plus software counter comparison	Protected image counters in the two slots	Lower candidate counter rejected; equal can pass this gate
Hardware rollback protection	Candidate counter versus platform-stored counter	Validation rejects a lower value; platform implementation remains a required dependency
Other option/mode combination	Not established by this table	Trace and qualify its own compiled path before approval

The overwrite guard checks whether the primary header magic is erased, not whether the complete primary header or image is valid. A malformed but non-erased magic value can still satisfy that guard; assess independent validity separately.

“Can pass this gate” does not mean the candidate necessarily installs or boots. Signature, layout, image selection and other checks still apply. A rejected candidate can also be invalidated in storage by the loader; preserve test copies before exercising these paths.

3. Specify the exact version ordering

The pinned comparator examines major, minor and revision components in order. The build number participates only when the corresponding build-number comparison macro is enabled. Do not assume a display string’s final number always changes eligibility.

For a hypothetical installed version 2.4.7+10, a candidate 2.4.7+9 compares equal when build-number comparison is absent and lower when it is enabled. The source’s rejection condition is less than zero, so equality is materially different from a policy requiring every accepted release to be strictly newer.

Write the expected equal-version behavior explicitly. If product policy forbids reinstalling an equal version, identify the actual enforcement mechanism rather than attributing that rule to a comparator that permits equality.

4. Distinguish software counter baseline from trusted counter storage

The software swap-counter path reads counter metadata from the installed image. In this tag, failure to obtain the primary image’s counter permits this eligibility check to continue; an unreadable or lower candidate counter fails once a primary counter was obtained. Other image-validation checks may still reject either image.

That behavior is not equivalent to a protected nonvolatile high-water mark. Treat a missing baseline as a separate fixture and document whether the product permits migration from images without that metadata.

With hardware rollback protection, image validation requires a valid counter and successful platform counter read, then rejects a candidate below the stored value. Equal counters remain possible even when software version labels differ.

The counter interface contract requires a fail-safe platform implementation. Before claiming hardware-backed protection, inspect that actual implementation, storage protection and failure behavior. Without it, stop at “configuration intent identified”; do not claim enforced rollback resistance.

5. Qualify the boundary cases on preserved fixtures

• Lower, equal and greater version tuples under the resolved comparison configuration.
• Only the build number changed, with the recorded build-number policy.
• Lower, equal and greater security-counter values.
• Missing or malformed protected candidate counter.
• Primary image lacking a usable software-counter baseline.
• Erased versus malformed-but-non-erased primary-header magic in the overwrite guard.
• TEST, PERM and REVERT requests as distinct paths.
• Counter-read failure in the platform-backed profile.
• Valid signature but unacceptable compared value, and an invalid-signature control.

Use recoverable development hardware or a qualified isolated harness, with original images and data preserved. The loader may erase or scramble rejected candidates. Do not run the matrix on an irreplaceable device, program irreversible counters for illustration, or change production key policy to make a fixture convenient.

6. Interpret acceptance narrowly

If an equal version is accepted, compare it with the actual less-than condition before calling it a defect. If an older software label passes with the same accepted security counter, that may match the counter policy while violating a separate product expectation.

If a downgrade fails before the comparison because its signature is invalid, the run has not demonstrated downgrade enforcement. Preserve both the verification result and the comparison-path evidence.

Close with the mode/option/macro matrix, comparator operands, equality policy, missing-baseline handling and counter-backend review. Counter advancement timing and interrupted commits require a separate analysis; identifying the comparison alone does not prove the stored minimum survives every reset.