Fallback mechanism for failed AB_SWAP update

[Shiv_peak]

Hello,
We are developing an application that uses the AB_SWAP mechanism of the HSE firmware on the S32K342 to perform OTA updates. We are currently activating the passive block once the passive region of the flash is entirely written to.
We were wondering whether there is a fallback mechanism that we can use to verify/check whether the image we are booting from is corrupted, and if we can fallback to the 'known good' active region that has become the passive region after resetting.
This arises from the fact that on some occasions, we overwrite the passive region without issuing a reset and midway through we reset the processor, resulting in a corrupted image in the flash. 

[lukaszadrapa]

Hi @Shiv_peak 

I answered very similar question a couple of days ago, please take a look at:

https://community.nxp.com/t5/S32K/S32K-OTA-Rollback/m-p/2400332/highlight/true#M60125

If you need more details, just let me know.

Regards,

Lukas

[Shiv_peak]

Hey @lukaszadrapa ,
Thanks for the clarification. We are still trying to understand which type of secure boot strategy to use in our application. Advance Secure boot seems a bit complicated with having to install the SMR and CR.

On the other hand, Basic Secure boot seems slightly easier to install but the exact implementation and installation details seem unclear.
I was wondering if you could provide some insight into these options. I am referring to the HSE B Reference Manual and was also wondering if there is any additional documentation I should be referring to for this.

Regards,
Shiv

[lukaszadrapa]

We provide this application note:

https://www.nxp.com/webapp/Download?colCode=AN13465

It’s updated version of Secure Boot application note v0.1.1.0 (AN744511) released in 2021 which can be downloaded from:

https://www.nxp.com/products/S32K3

Application note can be found here:

Documentation -> Secure Files -> Secure Boot Application note v0.1.1.0 (AN744511)

Associated demo project can be downloaded here:

Design Resources -> Software -> Secure Files -> SecureBootAppNoteDemo (SW745310)

The software was not updated, so use mentioned SW745310 if you are interested.

Other examples for secure boot can be found in HSE Demo Examples (recommended):

https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples

There are examples for all three modes – advanced secure boot, basic secure boot and SHE secure boot.

Generally, advanced secure boot mode is recommended. Yes, it is not trivial task to configure the secure boot in this mode. However, it provides the best protection and configurability. The advantage is that you can select any signature scheme you want,  you can cover multiple regions and you can configure different sanctions if the secure boot fails.

On other hand, basic secure boot mode always uses only GMAC tag which is calculated using a key derived from ADKP and it can cover one region only. If it fails, the device goes directly to recovery mode.

I recommend to study following projects in HSE DemoExamples:

S32K344_Advanced_SecureBoot

S32K344_Basic_SecureBoot

These are configuration projects which are supposed to protect application S32K344_SecureBootBlinky which is linked to those projects.

Regards,

Lukas

[Shiv_peak]

Can you also elaborate on what you mean by 'device goes in recovery mode' if the basic secure boot fails? Does this mean that the core will not be released from reset and there is no fallback or recovery in this case?
I ask because we want to have the functionality where if the secure boot fails, we boot another image, possibly in the passive bank.

[lukaszadrapa]

Take a look at section “2.6.1.3 Recovery Mode” in HSE firmware reference manual rev. 2.7.

In short, there are two modes:

JTAG based recovery mode – the device just hangs in endless loop in RAM (this piece of code is loaded to RAM by SBAF), so user can connect a debugger and perform some recovery steps.

Secure recovery mode – this needs to be enabled by attribute HSE_SECURE_RECOVERY_CONFIG_ATTR_ID. Notice that this is OTP attribute programmed to UTEST memory. This starts recovery image which needs to be verified first. So, it is similar to basic secure boot. If the verification fails, it goes to JTAG recovery mode.

The secure recovery mode can be used for recovery/rollback in runtime. But I do not recommend to run this from passive partition. All the code should be executed from active partition. In AB swap mode, you will have a copy of secure recovery image in both partitions anyway.

Another option is to put this code to data flash memory if there’s enough space.

[Shiv_peak]

Thanks for the clarity Lukas.
I will look into the application note and the HSE demo examples and revert back in case of any queries.

Regards,
Shiv