2312976_en-US

Yes

SYS_IMG KeyCatalog corrupted on S32G

Hi,

I'm using S32G2. SecureBoot is enabled. The IVT has properly defined my startup BootManager on M7, a location for the HSE_FW, and a location for the SYS_IMG within NOR flash. All these areas have backups also defined in IVT.

I have also enabled signatures for my BootManager at the end of the area. The SMR is properly defined. I managed to boot it many many times. I also managed to update the BootManager and re-sign it again. This involves to update SMR, and to update SYS_IMG . Backup of SYS_IMG was also re-generated and both written into NOR flash.

This update process has been done several times. No issues.

After many update cycles, my BootManager has stopped booting. The SYS_IMAGE passes the hseVerifySysImageSrv test. After inspecting the NOR flash, it seems to have a good header of 4KB, a good "HSE Configuration Data Set" of less than 8 KB, and a good "NVM Key Store Data Set" of less than 32KB according to the RM00301 HSE Firmware Manual.

Given that my BootManager no longer boots, the board does a reset after 1 second. After 5 resets, it goes to sleep.

How can I know if the problem is that the HSE didn't like the SYS_IMG, or the SYS_IMG has lost the SMR for my BootManager , or my BootManager key does not match the content ?

As said, hseGetSysImageSizeSrv reports a positive HSE_SRV_RSP_OK.

Is there an way to offline analyze the SYS_IMG ? I see that at 0x1000 it has the bytes "E1 E1 E1 E1" and after that there are 4 bytes that might be a counter. After that, the data is encripted so I don't know if the SMR and Key for BootManager are there.

Thanks,

Francisco

Re: SYS_IMG KeyCatalog corrupted on S32G

Hi,

Thanks for the reply. The hseVerifySysImageSrv_t is succesfull so it confirms that this SYS-IMG is somehow correct.

What I did was: save the bad SYS-IMG in some other NOR address . Point the IVT to a known valid SYS-IMG . Call hseVerifySysImageSrv_t pointing to the bad SYS-IMG is succesfull so it confirms that this SYS-IMG is Verified. But this doesn't garantee that the content includes the SMR or Keys for my BootManager, right ?

When IVT points to the bad SYS-IMG, then it does not verifies my BootManager which somehow indicates that the bad SYS-IMG is missing the SMR.

Is it possible to ask HSE at run-time to load the bad SYS-IMG, and then use Hse_GetKeyInfo to know if the keys are present ? I know that Hse_GetKeyInfo returns an error if the Key is not present, so this will tell me which keys are still available in my bad SYS-IMG .

Is there any way to load the bad SYS-IMG, and call smrVerifyReq (HSE_SRV_ID_SMR_VERIFY) ? That will tell me if the bad SYS-IMG has the SMR for my BootManager, or if it has lost it.

Thanks,

Francisco

Re: SYS_IMG KeyCatalog corrupted on S32G

Hello @nxg19026,

Regarding the offline review of the SYS-IMG, there is no procedure to check the encrypted contents, it does hold all the non-volatile information, however it is not accessible outside the HSE. About the possibility of the contents being corrupted, I find it quite unlikely, however, you can use the hseVerifySysImageSrv_t to double check if SYS-IMG in the flash memory is correct.

Furthermore, following what is mentioned in the HSE FW reference manual, if the SYS-IMG is corrupted, the HSE resets the device up to 8 times before changing to serial mode for recovery.

Let me know if the verification runs successfully.

Re: SYS_IMG KeyCatalog corrupted on S32G

Hello @nxg19026,

If the verification ran successfully that should mean the information in the SYS-IMG is correct. Regarging the run-time load, it is not possible to load a different SYS-IMG, the SYS-IMG load is done by the BootROM and that cannot be changed.

However, as I mentioned, if the SYS-IMG is really corrupt the chip does not boot, and therefore I do not see any indication that the SYS-IMG is the problem.

Can you elaborate more about what exactly does your BootManager does and how is it failing?

thanks

Re: SYS_IMG KeyCatalog corrupted on S32G

Hi,

Some more info: I'm using HSE rev2.1_s32g2xx_hse_fw_0.1.1_2.22.0_pb230810 , premiun version with more available keys.

One of the groups in aHseNvmKeyCatalog has 20 keys of hseKeyType_t HSE_KEY_TYPE_AES , each one has lenght 256.

After confirming that the verification via Hse_VerifySysImg was successful, the investigation is going in a different direction:

1) I flashed a non-signed BootManager, and also told IVT that I need no signatures. This allows me to extend BootManager with new debug functionality.

2) I flashed an old, valid SYS-IMG . I used Hse_GetKeyInfo to confirm that it has the key for BootManager.

3) I flashed the faulty SYS-IMG . Now Hse_GetKeyInfo tells me that the key for BootManager is no longer present.

For saving the SYS_IMG, I'm following the recommended process: hseGetSysImageSizeSrv , then hsePublishSysImageSrv, and using the Flash driver to save into NOR Flash.

So it seems that the my Update process has written a set of empty keys. I can only imagine that I have lost them because inadvertently calling hseFormatKeyCatalogsSrv_t (HSE_SRV_ID_FORMAT_KEY_CATALOGS).

Might it be that hsePublishSysImageSrv has retrieved the keys for another MuInstance ? I have defined all my keys for HSE_MU0_MASK and HSE_KEY_OWNER_CUST . As I understand, hsePublishSysImageSrv retrieves all the keys for all the hseMuMask_t's and all the hseKeyGroupOwner_t's , right ?

My BootManager works in the following way:

a) It takes 508 KB. The signature is in the last 4 KB. It is pointed by AppBL at IVT. It is started by a SMR . It has a Key of type HSE_KEY_TYPE_AES

b) There is a AppBL backup. It uses the same Key, but a different SMR.

c) Via communications, it can be updated into AppBL location. Note that AppBL-backup is present, to guarantee A/B

d) It generates a new Key and imports into its slot via targetKeyHandle. The counter is HSE_KF_MAX_KEY_COUNTER_VALUE . The authKeyHandle is HSE_INVALID_KEY_HANDLE The signature is re-written in the last 4KB.

e) The SMR is re-generated

f) It calls hseGetSysImageSizeSrv , hsePublishSysImageSrv , and writes the SYS_IMG

g) It flashes the binary into AppBL-backup, and does the same e) and f)

This has been working for a long time and many boards. It is just one board where the KeyCatalog is empty.

We can not read the register GSR from HSE because the board resets, and the PMIC is not initialized and it goes to sleep. I guess this is not really relevant, since I know that the KeyCatalog became empty.

Thanks,

Francisco

Re: SYS_IMG KeyCatalog corrupted on S32G

Hi,

Thanks for the reply. It gave me hints to test and re-analyze.

From this comment "It saves all the keys in the catalogs along with all non-volatile configuration for the HSE." -> I tested to load the SYS_IMG into a bootable configuration (i.e. without SecureBoot) and called Hse_GetKeyInfo. As it failed for the all the Keys , this proved that the Keys were absent.

You say that the volatile configuration is also present in the SYS_IMG. Is is possible to interrogate HSE to know which configuration is present ? It would help me to see which SMRs are still defined.

For a test, I tried to hseSmrEntryErase a SMR which I knew was never defined and yet I got HSE_SRV_RSP_OK. Can you confirm whether hseSmrEntryEraseSrv_t fails if the SmrEntry is missing or already erased ?

Similar to hseCrEntryEraseSrv_t . It seems that it always succeeds , even if the entry is absent.

As said, we are using the Premium HSE Firmware because we use 32 SMRs.

Is there any other info that I can extract from the SYS_IMG ? For example, at offset 0x1004 I got 4 bytes that look like a counter of the times the SysImage has been published.

"I imagine is multi-core " -> You are right this is a risk. Therefore the BootManager is single-core, and the interaction with the HSE is singleton, in order to minimize this risk .

From your comment "one of the programs overwrote the sysimage" -> As the sysimage is valid, it means that it was published. Otherwise the NOR flash would contain garbage, correct ?

Right now I'm investigating the possibility that the Keys were unintentionally erased. Either by Formating the KeyCatalog, or by hseEraseKeySrv_t with HSE_ ERASE_ ALL_NVM_
KEYS_ ON_MU_IF or HSE_ ERASE_KEYGROUP_ ON_MU_IF , althought I doubt it, since BootManager doesn't have any function implementing that.

Thanks,

Francisco

Re: SYS_IMG KeyCatalog corrupted on S32G

Hello @nxg19026,

Answering to this question: "Might it be that hsePublishSysImageSrv has retrieved the keys for another MuInstance?" From my point of view it would seem that in your application, which I imagine is multi-core, one of the programs overwrote the sysimage, which would cause the image to not have useful information and also be "correct".

For this questions "hsePublishSysImageSrv retrieves all the keys for all the hseMuMask_t's and all the hseKeyGroupOwner_t's , right ?" It saves all the keys in the catalogs along with all non-volatile configuration for the HSE.

From the description I can only conclude that there was an uninteded call for to publish the SYS-IMG which erased your keys. Another, quite unlikely posibility, is that that once chip has a silicon problem which at some point caused the SYS-IMG to be overwritten, however that is very difficult to diagnose.

With the current information I cannot offer you much more support, I apologize.

Let me know if you have more questions.

Re: SYS_IMG KeyCatalog corrupted on S32G

We found out that the SYS_IMG was not loaded despite hseVerifySysImageSrv_t being successful.

Investigation continues now internally with the support of NXP experts.

Topic is closed.

Thanks