Secure Boot Failure-Facing Reset after SMR configuration

[Prithviraj_k]

I'm encountering an issue while performing the On-Demand SMR verification of the application.

Board: S32G399RDB3 with an AUTOSAR application and NXP Boot on the M7 core.

I am carrying out secure boot for both the bootloader and the application image. I was able to successfully secure boot the NXP boot by configuring the SMR and CR. I am setting up the SMR with the following parameters mentioned in the Snip.

After loading the application to SRAM, I proceed with the SMR installation to prevent conflicts between the HSE and M7 core. I am only configuring the SMR and installing the application as outlined in the On-Demand Secure Boot documentation mentioned in the Snip.

After loading the application to SRAM, I proceed with the SMR installation to prevent conflicts between the HSE and M7 core. I am only configuring the SMR and installing the application as outlined in the On-Demand Secure Boot documentation.

The flow is as follows:

1. SMR INSTALL for the bootloader
2. SMR INSTALL for the application
3. CR INSTALL for the bootloader
4. Update the boot sequence in the IVT
5. Save the HSE SYS-IMG to flash
6. Perform MCU reset

However, after performing the MCU reset, the system resets again, and the control is not returned to the bootloader. Do you see any deviation in this process?

[carlos_o]

Hi @Prithviraj_k, 

Thanks for your questions.

Could you please provide the version that you are currently using for RTD, Tresos and HSE?

[Prithviraj_k]

Hello @carlos_o 
Thanks for the reply,
Version of the following 
Tresos-28.2.0
HSE-0_22_0
RTD-4_0_2

[carlos_o]

Hi @Prithviraj_k,

The internal team share the following:

The SMR entries which are not linked to the CR table are unverified until the host triggers.

It should not affect the boot sequence. Would you please check the CR table if it linked to the entry of application SMR entry. BTW, pInstAuthTag should pointer to the authentication tag of SMR entry, it should not be zero.

[Prithviraj_k]

Hello @carlos_o ,
I need  one clarification If my pSmrEntryInstall->entryIndex is 0 in smr installation, then crEntry.preBootSmrMap should also be 0 or 1 in CR installation?.
also I followed this document for on demand SMR .It mentions to provide 0 for pInstAuthTag

[carlos_o]

Hi @Prithviraj_k,

Q: I need one clarification If my pSmrEntryInstall->entryIndex is 0 in smr installation, then crEntry.preBootSmrMap should also be 0 or 1 in CR installation?.

A:Yes, in this case it should be also 0. 

The document you are following is an example for a Secure Bootloader verification of Linux Bootloader fip.bin not for an Autosar application, some this may change for your application.

Because that you need to pInstAuthTag should not be zero in your application and it needs to point to the authentication tag of SMR entry.

For more detail information you can refer to the HSE_H/M Firmware Reference Manual.

[Prithviraj_k]

I have identified the root cause of the reset issue: it was triggered by a Bootloader verification failure in the HSE. This failure occurred because the tag generated during flash write was not successfully written to the external NOR flash, which was passed to pInstAuthTag for verification. However, I'm now facing an issue where the NVM key stored in the HSE SYS-IMG becomes empty after the Bootloader calls Mcu_performreset. I believe that the scope of the NVM key should remain valid until an erase operation is performed, but it seems that the key is being lost prematurely. Do you have any insight into why this might be happening?

[carlos_o]

Hi @Prithviraj_k, 

This can be related to a note at the chapter 6.5 Updating SYS-IMG in external Flash of the HSE Firmware Manual, where it is mentioned as follows:

"If SYS-IMG is not saved to external Flash before the device is switched off or reset and while HSE_STATUS_PUBLISH_SYS_IMAGE was set to 1, part of the configuration parameters set by the host is lost."

Please refer to the HSE_H/M Firmware Reference Manual.

[Prithviraj_k]

Hi @carlos_o ,I am updating the SYS IMG to external flash as mentioned in document.
As i use same key to verify  bootloader and M7 application ,key was available for verifying the Bootloader and verified successfully but when i triggered the HSE_SmrVerify for application verification i get HSE_SRV_RSP_KEY_EMPTY error. Also I want to understand the flow on how HSE SYS IMG will be copied from external Flash to RAM for host.

[carlos_o]

Hi @Prithviraj_k ,

You can find some illustrations at the chapter 9.4 Publish SYS-IMG of the HSE_H/M Firmware Reference Manual that describes the behavior of how the HSE IMG SYS is copied from external flash to RAM.

When you say you are triggering the HSE_SmrVerify is with the hseSmrVerifySrv_t? 

[Prithviraj_k]

Hi@carlos_o thanks for the information on SYS -IMG.Yes i use hseSmrVerifySrv_t service and get Key empty as response.

[carlos_o]

Hi @Prithviraj_k , 

Please verify that the hseSmrVerifySrv_t are using the correct entryIndex.

[Prithviraj_k]

Hi @carlos_o ,
I use SMR index 2 to install and verify the SMR as shown in snip.

[carlos_o]

Hi @Prithviraj_k,

There you pass the 2 to your functions, but also that value needs to be in the entryIndex at the hseSmrVerifySrv_t structure. 

[Prithviraj_k]

Hello @carlos_o ,
I am passing 2 to entry index in the mentioned structure,even though this is taken care i am still facing the same issue(HSE_SRV_RSP_KEY_EMPTY)

[carlos_o]

Hi @Prithviraj_k,

At this point it is necessary to review your code to a better understanding of what can be causing the error. I will ask you to open a ticket with your issue, please refer to this community post at the description to follow-up.

[carlos_o]

Hi @Prithviraj_k, 

Thanks for sharing the versions of your setup. This question is out of my scope and expertise of the module, I will directly pass it to the internal team and wait for their response. I'll come ASAP with further information. We appreciate your patience. 

[vamsilanka]

Hi @carlos_o ,

It's been a month and the customer is still waiting on this, do you have any update on this ?