RidgeRun Platform Security Manual - NXP i.MX95 Yocto Build Process: Antirollback

🚧 Documentation is under development

The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.

Questions? Contact RidgeRun or email to support@ridgerun.com.

RidgeRun Platform Security Manual from RidgeRun

Contents Pin

Antirollback

This section explains how to plan and validate antirollback protection for a signed i.MX95 boot image. Antirollback prevents an older, correctly signed image from being accepted after a newer minimum version has been committed to the device.

Antirollback is different from rollback recovery. Rollback recovery returns to a previous known-good image when an update fails. Antirollback prevents returning to an older version that is below the accepted security-version floor. A production OTA design may require both mechanisms.

Warning

Warning: The ELE commit operation can update OTP or fuse-backed minimum-version state. After the commit, older images may no longer boot. The commit must not be executed on an ordinary development board or during documentation-only validation.

Prerequisites

Info

The BSP, Yocto source tree, build directory, Secure Boot signing flow, and image-installation process must already be prepared by following the Security Flow and Secure Boot sections.

The antirollback procedure uses:

Tool or artifact	Purpose	Reference
SPSDK `nxpimage`	Creates or signs AHAB images with the intended version value.	SPSDK installation guide and `nxpimage` documentation
SPSDK `nxpele`	Communicates with ELE for the commit operation and related status checks.	`nxpele` documentation
Two signed AHAB images	Provides the lower-version and higher-version images used by the validation sequence.	SPSDK i.MX95 antirollback example

The exact SPSDK version should be selected to match the i.MX95 BSP and the AHAB image format used by the build. The developer should verify the installed tools before preparing the test images:

nxpimage --help
nxpele --help

Plan the Version Sequence

The release process should assign a planned version sequence before creating images. The following example uses version N for the current image and N+1 for the newer image:

Image N       boots before the commit.
Image N+1     boots before the commit.
Commit N+1    updates the device minimum accepted version.
Image N       is rejected after the commit.
Image N+1     continues to boot after the commit.

The version must be placed in the AHAB container field associated with the intended rollback domain. NXP firmware and OEM firmware rollback domains are separate concerns; the version and commit target must not be mixed.

The version sequence should not be increased casually during development because the available OTP or fuse-backed version state is limited and the commit cannot normally be undone.

Prepare the Versioned Images

The Yocto build supplies the platform binaries and the Secure Boot build supplies the signed boot artifacts. The developer should create two isolated release inputs so that the image content, signing configuration, and version value for each release can be identified later.

The SPSDK AHAB configuration should contain the intended version value. The exact YAML field and command options depend on the selected SPSDK release and AHAB container type. The developer should use the i.MX95 antirollback example as the command reference rather than guessing the field name.

The image-generation flow is:

Build or collect the required Yocto boot binaries.
Prepare the AHAB configuration for image version N.
Sign the image with the approved Secure Boot key hierarchy using nxpimage.
Save the image, configuration, checksum, and tool version.
Repeat the process for version N+1 using a separate release directory.

Each signed image must remain compatible with the SRK hierarchy trusted by the target device. Changing only the version does not replace the normal AHAB signing and verification requirements.

Validate Both Images Before Commit

The commit must not be attempted until both images have been tested on approved rollback-test hardware.

Validate image N

Install image N using the approved signed-image path.
Boot the board and confirm that Secure Boot accepts the image.
Record the complete serial boot log and AHAB/ELE status.
Confirm the running image version from the release record or device software.

Validate image N+1

Install image N+1 using the approved signed-image path.
Boot the board and confirm that Secure Boot accepts the image.
Record the complete serial boot log and AHAB/ELE status.
Confirm that the required applications and recovery path still work.

The two images must boot successfully before the version floor is committed. A failed image must never be used as the image that advances the device minimum version.

Commit the New Minimum Version

The commit operation changes the device policy. A representative SPSDK command is:

nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB17 \
  commit -i NXP_FW_FUSE

The values in this example mean:

-f mimx9596 selects the i.MX95 device family.
-d uboot_serial selects the U-Boot serial communication path.
-p /dev/ttyUSB17 selects the serial device connected to the board.
commit requests the ELE version-floor update.
-i NXP_FW_FUSE selects the rollback domain in this example.

The exact interface, device family option, serial port, and rollback-domain identifier must be confirmed for the board and firmware being tested. The example must not be copied unchanged into a production procedure.

Before executing the command, the developer must confirm:

The board is approved for irreversible rollback testing.
Image N and image N+1 have both booted successfully.
The exact version being committed is N+1.
The selected rollback domain matches the intended AHAB container.
A signed recovery image remains compatible with the device trust hierarchy.
The complete serial console is recording.
The current fuse and lifecycle state have been captured.

The commit output and the post-commit ELE status must be saved with the release evidence.

Verify Antirollback Enforcement

After the commit, the developer should attempt to boot image N again. The expected result is:

the image remains correctly signed but is rejected because its version is below the committed minimum;
the device does not complete a normal boot with image N;
the serial output records the failure stage; and
image N+1 continues to boot successfully.

The developer should then restore the approved newer image or signed recovery image. The recovery path must be tested before the commit because antirollback can prevent older recovery images from booting.

Validation Evidence

The following material should be preserved for each antirollback test:

SPSDK version and command configuration;
image N and image N+1 checksums;
AHAB version values for both images;
Secure Boot signing-key identifier and SRK record;
successful boot log for image N;
successful boot log for image N+1;
exact rollback domain selected for the commit;
complete nxpele commit output;
post-commit ELE or AHAB status;
failed boot log for image N after the commit; and
successful recovery or image N+1 boot after the failed attempt.

Important Limitations

Secure Boot signatures alone do not provide antirollback. Before a version is committed, an older image may still boot if it is correctly signed and otherwise valid. Antirollback is enforced only when the selected version state has been committed and the boot flow checks that state.

The product should also define an emergency-recovery policy. An unrestricted downgrade path can defeat antirollback, while an overly restrictive policy can prevent recovery from a failed release. The accepted version floor, rollback domain, recovery image, and key-rotation process must therefore be reviewed together.

❯

Share This Page

Send Email Using