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.

BSD-3 license is acceptable (e.g. NXP-PAC), need to update deny.toml.

To-dos:

Move journal to external flash with flexSPI IP.
Use memory.toml for memory mapping.
Split MCXA ROM APIs as independent library under /libs
Update readme.

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?

diondokter · 2026-06-11T10:10:31Z

+        let flash = InternalFlash::new();
+        let journal = match FlashJournal::new::<JOURNAL_BUFFER_SIZE>(flash).await {
+            Ok(journal) => journal,
+            Err(_) => {
+                mcxa_error!("Critical: failed to initialize flash journal");
+                loop {
+                    cortex_m::asm::wfi();
+                }
+            }
+        };


I thought we weren't putting the journal in internal flash?
Or do we have a custom board impl for that? (privately)

That is an update that's needed here. Journal should be the first partition in external flash, since the internal flash doesn't support multiwrite

diondokter · 2026-06-11T10:20:04Z

How opinionated should this be? Currently this is a very specific implementation. Another mcxa user might want to store things in different locations.

Yea, agreed this is too opinionated. I think we should follow a similar method as was done on the RT6 part, where we can specify these using the partition TOML

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

JamesHuard · 2026-08-13T19:28:12Z

+        #[cfg(any(feature = "defmt", feature = "log"))]
+        info!("CMPA and CFPA are erased, will provision with initial state, will reset");
+        // causes a reset, so we will not return from this function. on next reset, IFR will have been provisioned and we will continue to bootloader.
+        match set_ifr_initial_config_and_reset() {


is this valid for any potential app example platform we might run on? For example, does this work as-is for EVK?

Yes, tested on 577 EVK, no change needed out of the box running in internal. But EVK will use port A for external flash, this configures port B. So you'd run from internal only on an EVK.

Product DKs (B** / W**) also work out of the box but they are already on port B.

JamesHuard · 2026-08-13T19:29:13Z

@@ -0,0 +1,134 @@
+# Custom probe-rs chip description for MCXA577.


Should these changes go upstream to MCXA.yaml?

Would be ideal, yes.

JamesHuard · 2026-08-13T19:29:48Z

    }

-    async fn check_and_boot(&mut self, slot: &Slot) -> BootError {
+    async fn check_and_boot<const JOURNAL_BUFFER_SIZE: usize>(&mut self, slot: &Slot) -> BootError {


Why was this needed?

The internal flash journal trait was changed, so to satisfy compile errors it was added. Once journal goes back to external flash this should be gone.

JamesHuard · 2026-08-13T19:30:31Z

@@ -0,0 +1,330 @@
+#![allow(clippy::not_unsafe_ptr_arg_deref)]


This belongs in its own ROM API crate, IMO.

Agreed, this is one of the listed to-dos.

JamesHuard · 2026-08-13T20:27:57Z

 It is only opinionated with regards to how the state is stored.

-Currently only supports the NXP IMXRT685S and IMXRT633S where it acts as a stage-two bootloader and copies the program to application RAM.
-Also contains a tool for signing images, flashing them to the device, setting fuses (or shadow registers) containing crypto keys,


but both of these second and third points are still true?

I completely botched the README... oops.

I have to redo the whole thing.

JamesHuard · 2026-08-13T20:28:22Z

 * at least two regions of any memory that will fit an application image.

-Using the library crate for your platform (like `ec-slimloader-imxrt`) you can then implement your own bootloader binary by calling the `start` function in the `ec-slimloader` library crate.
+Using the library crate for your platform (e.g., `ec-slimloader-mcxa`) you can implement your own bootloader binary by calling the `start` function in the `ec-slimloader` library crate.


reframing the doc here seems like a meaningless change?

README is screwed up, redoing it.

JamesHuard · 2026-08-13T20:29:02Z

-* how application images are loaded. For `ec-slimloader-imxrt` images are copied to RAM in a quite chip-specific way. Typically for other platforms you might want to swap images between on-chip NOR flash and external NOR flash. The latter method is not implemented in this repository (yet).
-* how application images are verified. By default the images themselves are not checked at all. `ec-slimloader-imxrt` leverages the native NXP authentication routines to check image integrity.
-* how application images are bootloaded, or in other words are jumped to. This differs for cortex-m or RISCV processors.
+* how application images are loaded.


raw delete of content here but leaving the header doesn't make much sense to me. If this is not consistent across platforms, then lets document that accordingly

JamesHuard · 2026-08-13T20:29:19Z

  If the application does not do this, the bootloader will load the old 'backup' image and mark the current boot as `failed`.

-For a full tour on how to use this framework, please refer to the `examples/rt685s` folder.
+For a full tour on how to use this framework for MCXA5xx, refer to the MCX examples.


again, seems odd to selectively change just this line but not the whole document

JamesHuard · 2026-08-13T20:29:50Z


 You can use the `USER_2` button the reboot into the bootloader, which will set an image to `failed` if it does not verify or if it was in `attempting` without putting the state in `confirmed`.
+
+The following describes the process for generating artifacts and signing/flashing for MCXA:


tbh you might want to just scrub the changes to this file, it's hard to see what the reason was for each independent edit, as they don't roll into the surrounding context meaningfully

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-13T19:54:26Z

+        // flash with ECC; re-programming a page without erasing first corrupts ECC, i.e. MCXA...)
+        //Note that this does mean number of journal entires are reduced.
+        // Falls back to 2-byte chunk for flash with WRITE_SIZE <= 2 (e.g. exsiting IMXRT WRITE_SIZE=2).
+        let incremental_offset = T::WRITE_SIZE.max(2);


For MCXA, WRITE_SIZE is 128, so each entry occuppies 128 bytes?

Shouldn't a 2 byte write be rejected if WRITE_SIZE is 128? That is, force the user to pass a 128-byte slice where the first 2 bytes contain the state and the remaining 126 are set to 0xff?

jerrysxie · 2026-08-13T19:58:55Z

@@ -87,10 +87,14 @@ impl<T: NorFlash> FlashJournal<T> {
    /// and are analysed, before reading the next block.
    /// A larger block size generally improves performance, and needs to be a non-zero multiple of 2 bytes.
    async fn compute_cache<const BLOCK_SIZE: usize>(inner: &mut T) -> Result<Cache, T::Error> {


The existing test only covers test with small write size, we should consider change the test parameter a bit to cover this new case with 128 bytes write size.

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?

jerrysxie · 2026-08-13T23:11:29Z

+    // Handle SlotRetryRequired differently - operation succeeded, just restart
+    if matches!(error, BootError::SlotRetryRequired) {
+        info!("Slot copy completed successfully, restarting bootloader for retry");
+        cortex_m::peripheral::SCB::sys_reset() // Proper system reset!


Non-blocking: we are baking in a very arch specific intruction here, which will be come a problem if we support other arch with this bootloader.

This will be removed as part of the design change.

Do you mind detailing the design change you have in mind? I'd consider this a Blocker for merging this PR.

jerrysxie · 2026-08-13T23:19:34Z

    warn!("Failed to boot {:?} in {:?} because {:?}", intent, slot, error);

+    // Handle SlotRetryRequired differently - operation succeeded, just restart
+    if matches!(error, BootError::SlotRetryRequired) {


So if the backup slot is bad, we would continue copy it into A and reset. This reset/copy loop will wear out the flash. In the old case, if the backup slot fails, we abort. Is there any reason why reset is perferred in MCXA's implementation?

This was the original type 1 design, this will be updated with 3A slot design (no erase/copy, only bank swap), I'm working on stripping out all of this code. This was originally going to be changed as a separate PR after this one is merged, but given the risk to RT6 due to ec-slimloader crate changes, I will make that change now.

jerrysxie · 2026-08-13T23:28:51Z

+
+// The following CFPA fields are documented here for reference and can be localized when
+// readers/writers are added for them:
+// const CFPA_PAGE_VERSION: u32 = IFRConfigAreaBase::Cfpa as u32 + 0x0014;


Is there a NXP reference for everything here?

Yes, MCXA Reference manual attachment called IFR.xlxs.

jerrysxie · 2026-08-13T23:30:29Z

@@ -0,0 +1,23 @@
+[package]
+name = "mcxa-security-provisioning"


This is not covered in CI. Is this a library that we want to keep?

Good catch! Will add to CI, yes this does the provisioning and fusing steps (which are now part of the SBL/app themselves).

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.

felipebalbi · 2026-08-14T15:55:29Z

+    let input_data: [u8; 256] = core::array::from_fn(|i| i as u8);
+
+    for (index, byte) in input_data.iter_mut().enumerate() {


input_data is immutable. You can borrow it mutably. This PR was not compiled, was it?

It was compiled, see CI results for previous commit.

Looked like

let mut hash_result = [0u8; 48]; let mut input_data = [0u8; 256]; for (index, byte) in input_data.iter_mut().enumerate() { *byte = index as u8; }

The code block wasn't removed when the from_fn was added. Removing now.

felipebalbi · 2026-08-14T15:57:34Z

Write path was not patched for 128 byte writes. Here's a test that causes it to panic:

#[test] fn journal_write_size_128() { let mut mock: MockFlashBase<3, 128, 8> = MockFlashBase::new(None, false); embassy_futures::block_on(async { let mut journal = FlashJournal::new::<256>(&mut mock).await.unwrap(); let state = State::new(Status::Initial, Slot::try_from(2).unwrap(), Slot::try_from(1).unwrap()); journal.set::<256>(&state).await.unwrap(); assert_eq!(journal.get(), Some(&state)); }); }

felipebalbi · 2026-08-14T16:07:23Z

+    if let Some(current) = load_lifecycle_from_cfpa() {
+        if !current.can_advance_to(next) {
+            return Err(CfpaWriteError::LifecycleRegression);
+        }
+    }


are you skipping a verification that current is equal to From? It seems like it. That would mean we can trick the system into transitioning to states we didn't want.

nboot.rs line 296

pub const fn can_advance_to(self, next: Self) -> bool { next.rank() >= self.rank() && (self as u32 != next as u32) }

We allow equal weight but not identical LC advances (e.g. Develop to Develop 2, but not Infield to Infield).

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 6 commits July 30, 2026 15:44

address NbootCtx inputs on an unprovisioned MCU

af996ef

Add flexSPI boot config to first setup

3db3385

SBL first provision; cargo fmt; deny and check updates

643c6e3

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

Update app main.rs

0d2e8c0

felipebalbi reviewed Aug 14, 2026

View reviewed changes

		@@ -0,0 +1,134 @@
		# Custom probe-rs chip description for MCXA577.

		@@ -0,0 +1,330 @@
		#![allow(clippy::not_unsafe_ptr_arg_deref)]


		You can use the `USER_2` button the reboot into the bootloader, which will set an image to `failed` if it does not verify or if it was in `attempting` without putting the state in `confirmed`.

		The following describes the process for generating artifacts and signing/flashing for MCXA:

		@@ -0,0 +1,23 @@
		[package]
		name = "mcxa-security-provisioning"

		let input_data: [u8; 256] = core::array::from_fn(\|i\| i as u8);

		for (index, byte) in input_data.iter_mut().enumerate() {

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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

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 Aug 14, 2026 •

edited

Loading

alamfarjadf Aug 14, 2026 •

edited

Loading