Add support for PQC secure boot with MCXA 5xx family of MCUs by alamfarjadf · Pull Request #36 · OpenDevicePartnership/ec-slimloader

alamfarjadf · 2026-04-02T20:29:28Z

Adding ROM API support for MCXA 5xx family with Post-Quantum Cryptography hybrid secure boot (ML-DSA-87 and EC-DSA P384).

Added ec-slimloader-mcxa under libs and mcxa-577 examples (bootloader and blinky).

Validated on MCXA577 eval kit with hybrid signed AHAB MBI images which successfully authenticate and boot up.

Not yet added to PR: Imaging tools for MCXA (being worked on as an independent library).

To-dos:

Move journal to external flash with flexSPI IP (already done to minimize RT6 impacts).
Use memory.toml for memory mapping.
Split MCXA ROM APIs as independent library under /libs
Update readme.
General ROM API safety and type improvements.
Add journal update to App.

diondokter

Is there any split image support yet? If there is I can't find it (so please point me to it 😊)
Or are we assuming the ROM memory mapped it for us already?

JamesHuard · 2026-06-11T15:32:12Z

Is there any split image support yet? If there is I can't find it (so please point me to it 😊) Or are we assuming the ROM memory mapped it for us already?

The image header that the NXP ROM APIs/ROM Loader use has a section for identifying multiple images. The thought here is that it'd be a 'no-op' from an implementation perspective of the SBL firmware to support split-image, because it's already baked into the infra. The change then is in the build tooling to actually generate these additional fields and hashes.

That's also where the open question is to NXP around if the secondary image(s) are simply hash verified or included in the full image signature block.

alamfarjadf · 2026-06-11T20:58:27Z

Is there any split image support yet? If there is I can't find it (so please point me to it 😊) Or are we assuming the ROM memory mapped it for us already?

@diondokter There is no split image support yet.

From my understanding, the split image on the verification side should be opaque to the caller, IF the image is built correctly (The idea here is that the second executable occupies the area for the CRC binary and is hashed and verified automatically by the APIs). But that idea hasn't been validated yet partly because I haven't been able to generate a split image binary yet.

We have reached out to NXP for further clarification and are awaiting their response.

When we have a split binary, the API will use the single AHAB container to hash both binaries and validate them, so infrastructure needed is mostly on the artifact generation side (which is not published as part of this public PR yet but available in private repos).

diondokter

Thanks for the responses so far!

What's the reason for trying to massage ec-slimloader into supporting both chips and a radically different way in how the code is executed?

The non-imxrt6xx parts are pretty small. All ec-slimloader does is a little bit of in-flash state management, verifying the image and then jump to it.

But for mcxa, the verification is different. And because we're gonna be running in flash, we need to be able to swap partitions, which means that the state management needs to change too. All that's left is doing the boot jump which is like 20 lines of code.

So why take on the complexity of making everything share the same codebase and structure?

diondokter · 2026-06-15T12:41:11Z

Ok, I've been trying to build this PR and that just doesn't work.

Wrong embassy-time imports (though I could fix that)
target folders not in gitignore
builds on an embassy-mcxa branch that isn't able to be built in CI: [MCXA] make SGI drivers compatible with embassy-rs peripheral style embassy-rs/embassy#5612

JamesHuard · 2026-06-15T15:26:53Z

Thanks for the responses so far!

What's the reason for trying to massage ec-slimloader into supporting both chips and a radically different way in how the code is executed?

The non-imxrt6xx parts are pretty small. All ec-slimloader does is a little bit of in-flash state management, verifying the image and then jump to it.

But for mcxa, the verification is different. And because we're gonna be running in flash, we need to be able to swap partitions, which means that the state management needs to change too. All that's left is doing the boot jump which is like 20 lines of code.

So why take on the complexity of making everything share the same codebase and structure?

This is a fair question.

The main thing I think we want is a common interface to the boot sequencing, particularly the journal management and rollback behaviors we want to be 'the same'. We'd like to have a common 'entry point' for various products/OEM lines that give a standard set of behavioral guarantees, even if the underlying hardware mechanisms (secure signing checks, memory layouts, extra steps) are radically different. Almost all, or perhaps all, of this is achieved through the Journal and banking management.

If the current structures/interfaces are too restrictive and getting in the way, then let's evolve. If that means a new interpretation of 'ec-slimloader' as just a trait and then some chip-specific impl's of that trait, I think that's fine.

What do you see as the lowest friction approach here? From my "500-meter high" view, I'd think the basic bootloading process is 'the same', that is:

Setup hardware
Read journal state
Either load valid image, or engage rollback recovery

2&3 being 'the same' is the useful thing here. That could easily be a small helper function on top of a trait that consumes the journal and hardware instances, which I think isn't too far off from what we have today, but there might be too much coupling here if it adds friction. I'm totally open to restructuring to make our job here easier

alamfarjadf · 2026-06-15T17:32:19Z

Ok, I've been trying to build this PR and that just doesn't work.

Wrong embassy-time imports (though I could fix that)

target folders not in gitignore

builds on an embassy-mcxa branch that isn't able to be built in CI: [MCXA] make SGI drivers compatible with embassy-rs peripheral style embassy-rs/embassy#5612

For 1, The embassy dependencies have not been updated in a while.

Added gitignore.

For 3, The CI build for that branch fails because chip JSON files in NXP-PAC are missing the SGI clock and power gating attributes. I was going to update them but never got the time. Once the SGI PAC is re-generated with the attributes, it will build successfully (does so in local).

diondokter · 2026-06-22T12:38:18Z

Validated on MCXA577 eval kit with hybrid signed AHAB MBI images which successfully authenticate and boot up.

@alamfarjadf do you have a script lying around with which you did this? Or do you have it written down.
If not, I have to duplicate the time looking into this

alamfarjadf · 2026-06-22T21:02:36Z

Validated on MCXA577 eval kit with hybrid signed AHAB MBI images which successfully authenticate and boot up.

@alamfarjadf do you have a script lying around with which you did this? Or do you have it written down. If not, I have to duplicate the time looking into this

@diondokter Are you interested in the AHAB signed image generation process?

Yes, I have a CLI tool that does this. I just gave you access to the private repo with the tool (ahab-mbi-tool). Build it, run the .exe with the --build path and the blinky BIN file and you will be able to generate a signed MBI image.

Caveats:

You need ECDSA keys (public and the corresponding signer) and MLDSA-87 keys. The current MLDSA keys are from TSS' auto-signer CLI tool (which you would need to separately get access to). For signing the image, you can use the tool to sign ECDSA and MLDSA.

OR are you simply interested in the signed binaries to flash? On an "un-provisioned" eval. kit, you can flash both binaries (BL and blinky app) in the corresponding flash locations and it should validate and boot (dev mode).

To provision the MCU, refer to mcxa-provisioning part of this PR.

…nctions

JamesHuard

I understand there's a desire to merge this in quickly to unblock follow up workstreams, and while some of the changes we'll need I could see us easily following up on, I can't in good conscience sign off on this until we're at least sure the changes introduced to the generic components that touch IMXRT aren't themselves breaking changes for those platforms. Those at minimum need to be addressed prior to check in, IMHO

alamfarjadf · 2026-08-13T20:38:41Z

I understand there's a desire to merge this in quickly to unblock follow up workstreams, and while some of the changes we'll need I could see us easily following up on, I can't in good conscience sign off on this until we're at least sure the changes introduced to the generic components that touch IMXRT aren't themselves breaking changes for those platforms. Those at minimum need to be addressed prior to check in, IMHO

Yes, IMXRT is untested. But the scope of impact to IMXRT is limited via the ec-slimloader crate itself, not libs/IMXRT.

Update: Working on integrating mcxa.rs External journal so all changes impacting RT6 can be undone.

Co-authored-by: Jimi Huard <james.huard@microsoft.com>

jerrysxie

Not done with the review yet, posting comments I have so far.

jerrysxie · 2026-08-13T20:04:13Z

+num_enum = { version = "0.7", default-features = false }
+device-driver = "1.0"
+
+[patch.crates-io]


Can we point to crates-io instead? Does embassy need to do another release?

felipebalbi · 2026-08-14T15:51:43Z

It seems to me that this app should be "complete". That is, it should open the journal and mark it Confirmed. Examples set the patterns folks will end up using.

Good call, I will add this.

jerrysxie · 2026-08-17T20:56:41Z

@alamfarjadf Is there more changes coming for this PR? Or is this is the first PR in a series of PRs? It sounds like we intend to do a design change, not sure if the code we are reviewing in this PR will be relevant or not after the design change?

alamfarjadf · 2026-08-17T21:38:34Z

@alamfarjadf Is there more changes coming for this PR? Or is this is the first PR in a series of PRs? It sounds like we intend to do a design change, not sure if the code we are reviewing in this PR will be relevant or not after the design change?

@jerrysxie Yes, I am changing the journal to EXTERNAL flash with flexSPI IP commands, also getting rid of the erase-copy-verify flow.

A lot of the code will not be relevant (completely removed) after this next commit. However, additional design changes should be incorporated as separate PRs after.

Both of these should reduce the impacts to IMXRT.

alamfarjadf · 2026-08-18T16:52:45Z

Is there any split image support yet? If there is I can't find it (so please point me to it 😊) Or are we assuming the ROM memory mapped it for us already?

Update: It is now confirmed that no change is needed on the SBL side for a split image, as long as the generator correctly hashes and places the correct metadata in the image array index.

diondokter · 2026-08-19T08:53:59Z

All the examples should follow the same names. So this example should be called examples/mcxa-577/application and the bootloader should be examples/mcxa-577/bootloader

diondokter · 2026-08-19T09:02:59Z

+embassy-sync = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-mcxa = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0", default-features = false }
+embassy-executor = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0", default-features = false }
+embassy-time = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+
+[patch.crates-io]
+embassy-embedded-hal = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-executor = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-executor-macros = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-futures = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-hal-internal = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-sync = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-time = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-time-driver = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }
+embassy-time-queue-utils = { git = "https://github.com/embassy-rs/embassy", rev = "f21d63db2d104a3b4c070408e529c109a64e65b0" }


These should used released versions of embassy (when available, so only mcxa should be a git dep)

diondokter · 2026-08-19T09:11:19Z

+/// distinct from section 1's sequential RGB pattern.
+#[link_section = ".text_flash1"]
+#[inline(never)]
+async fn flash1_pattern(


Have you checked where this is actually placed? In the memory.x there's no section defined with this name, so it's not clear to me this actually works.

I tried compiling the example to check myself, but it doesn't compile. The security provisioning crate is broken and even then there's stuff missing like a flash1.x file and the partition manager setup.

diondokter · 2026-08-19T09:12:27Z

+    File::create(out.join("flash1.x"))
+        .unwrap()
+        .write_all(include_bytes!("flash1.x"))
+        .unwrap();


This file doesn't exist. Also if it did exists, it wouldn't do anything. Just put it in the memory.x or if you really want to keep it separate, include the file from the memory.x

diondokter · 2026-08-19T09:14:03Z

+cortex-m = { version = "0.7", features = ["critical-section-single-core"] }
+cortex-m-rt = { version = "0.7", features = ["set-sp", "set-vtor"] }
+defmt = "1.0"
+defmt-rtt = "1.0"
+embassy-mcxa = { workspace = true, features = ["rt", "defmt", "mcxa5xx"] }
+embassy-executor = { workspace = true, features = ["platform-cortex-m", "executor-thread"] }
+embassy-time = { workspace = true, features = ["defmt", "defmt-timestamp-uptime"] }
+panic-probe = { version = "1.0", features = ["print-defmt"] }


This needs to be more consistent. Use the workspace or don't.

diondokter · 2026-08-19T12:46:55Z

+    }
+}
+
+pub type BootloaderTree = RomApi;


diondokter · 2026-08-19T12:48:16Z

+/// Helper function to get a pointer to the flash driver API from the ROM API tree.
+pub fn flash_driver() -> FlashDriver {
+    // Match NXP usage: g_bootloaderTree->flashDriver->...
+    // The bootloader tree stores a direct pointer to the flash driver interface.
+    bootloader_tree().flash_api()
+}


Useless helpers (below too). People can call rom_api().flash_api() themselves just fine and that's a lot clearer then what's actually being done

diondokter · 2026-08-19T13:01:04Z

+/// In dev mode, if the RKTH derived from the image does not match the ROTKH in CMPA, it will be copied to the ROTKH to allow authentication to proceed (this allows flexibility in dev mode since keys may not be provisioned yet),
+/// but in production mode, a mismatch will cause authentication to fail (to prevent unauthorized images from being authenticated).


This should not be in here IMO. This just makes the barrier between accepting and not accepting an image only one cmp instruction that can be influenced by a simple fault injection. NXP spends a lot of engineering effort into their firmware to prevent that from being possible, but that's all for naught if we are not careful.

If people want to make it easy to work with in dev mode, then they just need to update the CMPA/CFPA pages to accept all images or use a different bootloader that just jumps to whatever is in the app slots.

Not doing this also makes the entire bootloader half as complex

This is for factory bring up/provisioning. Without this, the first images won't boot. We can discuss specifics offline.

On the security side, all debug ports are locked once Secure Boot is provisioned. However, you bring up a good point. Currently the is_dev_mode() is acting as a "God Boolean", a good target for hardening.

I will re-work the decision path to be more fault/glitch resistant.

But then how did the bootloader already boot? It went through the same checks except the ROM did it.
I don't see how you can get to that point, but have the bootloader properly set up, but not the application.

I know roughly what the provisioning will look like. But that could change the settings of the types of images it accepts. Another way would be to sign the provisioning firmware with the same keys across the board and then once the provisioning is done, revoke that key.

These both seem so much more preferable to putting so much complexity in a bootloader that is not updatable.

And then still, say it all makes sense and the existing flow is what we want, why not just jump to the image? Why verify it's signed with a signature we're just making up? That's just doing pointless work.

The only thing I can come up with is that you verify the image is correct (apart from its signature). But that's also not useful to know, because the image you're checking is the provisioning image.

For first boot, secure boot remains off, so ROM does not validate the SBL signature. Secure Boot is off by default behavior until provisioned/fused. The SBL will always authenticate one of the app slots (active / backup).

There is no more provisioning firmware, the libraries for provisioning will become part of the actual image binary.

There is an effort ongoing regarding test/production signing criteria in factory, details of which we can discuss offline, but we are moving away from the key revocation model as a result.

The SBL and app image(s) will be signed by the same trust chain; it's just that until secure boot is turned on it's using that image embedded hash so the bootloader can authenticate it. Once secure boot is turned on, the IFR becomes the source of truth. Since there is no more re-programming (there is no "load provisioning image, then replace with app image"), this allows the intended setup to boot for the first time at the factory temporarily, until the factory flow provisions and fuses the device, at which point the root of trust is permanently set. Since no reprogram, there is one shot to make sure we get to a bootable provisioning sequence when device is first powered on.

Some of the details can not be discussed publicly, but we can setup time to discuss offline.

alamfarjadf added 5 commits April 2, 2026 12:20

add MCXA577 bootloader, blinky app, and ec-slimloader-mcxa library

5ab9523

fix embassy dependency resolution and clippy warning

e6c73e3

remove load.rs from PR (kept locally, unused)

6377471

Merge branch 'main' into mcxa-577-bootloader

d5f2142

git dep changes and SGI signature updates; add rustdoc comments

502cd91

jerrysxie assigned jerrysxie and unassigned jerrysxie Apr 7, 2026

alamfarjadf commented Apr 9, 2026

View reviewed changes

Comment thread libs/ec-slimloader-mcxa/src/lib.rs

alamfarjadf added 2 commits April 15, 2026 09:26

Merge branch 'main' into mcxa-577-bootloader

e0f5580

mcxa cmpa/cfpa provisioning

f185706

alamfarjadf force-pushed the mcxa-577-bootloader branch from 08f268c to f185706 Compare April 27, 2026 20:14

alamfarjadf added 4 commits May 15, 2026 18:43

fix STRIDE / hyenas CWE issues

13e2e38

Harden CMPA scratch lifecycle staging

59d2344

Merge branch 'main' into mcxa-577-bootloader

bbfa20c

Merge branch 'main' into mcxa-577-bootloader

27d4f5f

diondokter reviewed Jun 11, 2026

View reviewed changes

diondokter reviewed Jun 15, 2026

View reviewed changes

Comment thread libs/ec-slimloader-mcxa/src/rom_api.rs Outdated

Comment thread libs/ec-slimloader-mcxa/src/rom_api.rs Outdated

gitignore

fb0c240

alamfarjadf added 5 commits July 9, 2026 15:55

align embassy dependencies; use cortex-m reset; remove OTP ROM API fu…

4a573ec

…nctions

lifecycle provisioning updates

4537a8b

provisining flow updates

b517176

consolidate provisioning interface

3e9eeaa

jump update, use header validation; ROTKH provisioning updates

78ffbcf

alamfarjadf added 3 commits August 11, 2026 13:11

add missing toml files

0001414

security provisioning standalone cargo.toml

6746b85

exclude MCXA from linux target in CI

ae68481

alamfarjadf marked this pull request as ready for review August 11, 2026 22:15

alamfarjadf requested a review from a team as a code owner August 11, 2026 22:15

alamfarjadf requested review from RobertZ2011, felipebalbi, tullom and williampMSFT August 11, 2026 22:15

jerrysxie self-assigned this Aug 13, 2026

JamesHuard reviewed Aug 13, 2026

View reviewed changes

Update examples/mcxa-577app/app/src/main.rs

f38dd33

Co-authored-by: Jimi Huard <james.huard@microsoft.com>

jerrysxie reviewed Aug 14, 2026

View reviewed changes

felipebalbi reviewed Aug 14, 2026

View reviewed changes

Comment thread examples/mcxa-577app/app/src/main.rs Outdated

Update app main.rs

0d2e8c0

felipebalbi reviewed Aug 14, 2026

View reviewed changes

Comment thread libs/ec-slimloader-state/src/flash.rs

Comment thread mcxa-security-provisioning/src/lifecycle_provisioning.rs Outdated

ext-flash journal; type 3A bank swap journal; address comments

eea3ebe

alamfarjadf requested review from JamesHuard, diondokter, felipebalbi and jerrysxie August 18, 2026 18:16

alamfarjadf added 3 commits August 18, 2026 12:32

remove erroneous imxrt dep. from mcxa-provisioner

57b2f3a

defmt and mcxa app config updates

f1f39e0

re-enable full authentication flow with EXT flash journal

46f4df4

diondokter reviewed Aug 19, 2026

View reviewed changes

		/// In dev mode, if the RKTH derived from the image does not match the ROTKH in CMPA, it will be copied to the ROTKH to allow authentication to proceed (this allows flexibility in dev mode since keys may not be provisioned yet),
		/// but in production mode, a mismatch will cause authentication to fail (to prevent unauthorized images from being authenticated).

Uh oh!

Conversation

alamfarjadf commented Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

diondokter left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JamesHuard commented Jun 11, 2026

Uh oh!

alamfarjadf commented Jun 11, 2026

Uh oh!

diondokter left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

diondokter commented Jun 15, 2026

Uh oh!

JamesHuard commented Jun 15, 2026

Uh oh!

alamfarjadf commented Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

diondokter commented Jun 22, 2026

Uh oh!

alamfarjadf commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JamesHuard left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alamfarjadf commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jerrysxie left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jerrysxie commented Aug 17, 2026

Uh oh!

alamfarjadf commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alamfarjadf commented Aug 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

alamfarjadf commented Apr 2, 2026 •

edited

Loading

alamfarjadf commented Jun 15, 2026 •

edited

Loading

alamfarjadf commented Jun 22, 2026 •

edited

Loading

alamfarjadf commented Aug 13, 2026 •

edited

Loading

alamfarjadf commented Aug 17, 2026 •

edited

Loading

diondokter Aug 19, 2026 •

edited

Loading

alamfarjadf Aug 19, 2026 •

edited

Loading