I encountered the following problems when debugging Advanced_SecureBoot Project, please help support.
my project test on s32k312.
1.The Secure Boot CFG result is as follows
2. I change to secure boot by setting BOOT_SEQ
but ,my app can not be boot,Please help analyze the reason, thank you very much
Hello @luhaiou_autolink,
I checked this situation and I detected that the CMAC tag value has not been updated yet at the address 0x584000.
Pass:
Fail:
Best regards,
Dan
Hello @luhaiou_autolink,
1. Did you define IVT_BOOT_CFG_WORD_BOOT_SEQ correct as below?
#define IVT_BOOT_CFG_WORD_BOOT_SEQ (1 << 3)
2. Did you implement Advanced_SecureBootps steps correct?
Best regards,
Dan
1. Did you define IVT_BOOT_CFG_WORD_BOOT_SEQ correct as below?
#define IVT_BOOT_CFG_WORD_BOOT_SEQ (1 << 3)
Yes.
After the Secure Boot configuration was completed, I set the BOOT_SEQ bit and re-downloaded it to the MCU,
but ,my app can not be secure boot.
2. Did you implement Advanced_SecureBootps steps correct?
Each step of the configuration Advanced_SecureBoot has a corresponding log output
You can refer to the main.c .text file.
My project was tested on the s32k312,
The versions of HSE_FW and SBAF are shown in the figure below
My demo is based on the following example provided by NXP,
SW745310-SecureBootAppNoteDemo(1.0)
S32K3_HSE_DemoExamples.exe
Hello @luhaiou_autolink,
Following the Secure Boot project of NXP, the IVT was updated by code instead of adding IVT_BOOT_CFG_WORD_BOOT_SEQ into the ivt_flash array as your code. And maybe, this caused your program boot to fail.
From my point of view, you should remove IVT_BOOT_CFG_WORD_BOOT_SEQ and update IVT as the sample project of NXP.
Best regards,
Dan
Thanks for your suggestion,
1. I've tried this way, and when modifying the IVT_0,
UpdateIvt( BLOCK0_IVT_ADDRESS, BLOCK0_IVT_ADDRESS, SECURE_IVT ),
this step produces hard_fault, probably the flash access function is restricted when accessing the same FLASH BLOCK.
You can try debugging on the same hardware platform (s32k312), and using the same software platform (SBAF: 0.13.0.0.8.0, HSE_FW: 0.13.0.1.2.1), thank you very much
2.Refer to the demo S32K344_Advanced_SecureBoot in the S32K3_HSE_DemoExamples.exe,
and also does not update the IVT through code, but directly modifies the IVT and then compiles and downloads it
Hello @luhaiou_autolink,
I used the S32K312EVB board to test your project with some modifications related to updating the IVT by code as below steps:
Step 1: Uncomment updateIvt statements.
Step 2: Put C40_Ip function on RAM by actions:
2.1 Replace C40_Ip.c and C40_Ip.h file by these files in the S32K312_SecureBootCfg_EVBQ172_201_350_FW0210 project.
2.2: Comment line 1970 in the C40_Ip_MainInterfaceHVJobStatus() function in the C40_Ip.c file because the OsIf_GetElapsed() function will be put on Flash.
After do the above steps, I link my application in the linker in your project.
Next, I debug your project on S32DS and when the program configured secure boot completed, I caused a functional reset by pressing reset button (SW3) then application was performed (green led was blinking and the smrstatus[0] and smrstatus[1] both equal to 1 - secure boot was performed successful).
This is the log of cl_factory_s32k312_hse_fw_install project:
And this is log of secure boot application (after I pressed reset button).
The above image indicated that the advanced secure boot was performed successful.
I'm going to send your project modified and my secure boot application via email.
Best regards,
Dan
Hello Dan,
I've fetched your project, thank you very much.
Putting the flash access code in ram solves the RWW (ready while write) problem of FLASH,
and your modification to the flash driver is very useful for me.
But the problem I mentioned in my last email needs your help to solve.
It may be that the description in the last email was not detailed enough, so I will describe the problem in detail again.
The demo I provided to you will successfully implement the SecureBoot configuration and jump to the app successfully.
The problem is that when the configuration is completed and the app is successfully launched,
when you use PE online debugging again, it will cause the HSE_FW to work abnormally,
and it feels like the previously installed key is corrupted, and you have to reformat the key catlog and reinstall the key.
The video file I provided earlier,2024-01-29-16-12-29.mp4,The main operation process is:
cfg(with BOOT_SEQ = 1)->reset->app boot successfully->modyfy cfg project->debug again->HSE_FW fail
You can also replicate this phenomenon in your own projects.
1.Uncomment
2.debug again with PE,it will stop here
Hello @luhaiou_autolink,
To solve this issue, please add two statements into else as below:
Best regards,
Dan
There is also a doubt about Advance Secure Boot, which involves the design of our software architecture.
Our products need to realize the upgrade function of APP. Our software is designed to configure the Advance Secure Boot while the product is in the factory.
After that, we provide an app upgrade package to replace the original app, and our upgrade package is with Cmac_tag.
cmac_tag_first,cmac_tag_new1,cmac_tag_new2,,, are different.
However, after updating the app_new and cmac_tag_new, I can't start the app normally.
I personally understand that when installing SmrEntry, the important information is the smr_src, smr_size, key_handle, authentication scheme, cmac_tag_pointer and legth.
I have always understood that cmac_tag_pointer is provided with location information, and the specific content of this location can be different, as long as it matches the calculation result of the corresponding region content.
If the HSE_FW also records the specific content of the cmac_tag_pointer, then the SMR entry must be reconfigured for each APP upgrade, which is too inflexible.
I hope my understanding is wrong, and I look forward to hearing from you,
Here's how I tested it：
1.Create new branch
1.1 new branch of cl_factory_s32k312_hse_app0_blinky Project
1.2 new branch of cl_factory_s32k312_hse_fw_install Project
2.modify cl_factory_s32k312_hse_app0_blinky Project
2.1.modify cl_factory_s32k312_hse_app0_blinky ld file
2.2 modify main.c
main.c of cl_factory_s32k312_hse_app0_blinky is shared with cl_factory_s32k312_hse_fw_install ，Store in cl_factory_s32k312_hse_fw_install project，if you use git,pay attention to it
3.Get app_new de cmac_tag
3.1 compile cl_factory_s32k312_hse_app0_blinky
3.2compile cl_factory_s32k312_hse_fw_install
3.3 debug cl_factory_s32k312_hse_fw_install , get cmac_tag in log
3.4 modify main.c with cmac_tag in step 3.3
4.Debugging app_new
4.1 compile cl_factory_s32k312_hse_app0_blinky
4.2compile cl_factory_s32k312_hse_fw_install
4.3Debug cl_factory_s32k312_hse_fw_install
APP_boot ok,
Now, cl_factory_s32k312_hse_app0_blinky.hex image is with cmac_tag，Save this file
5. Both projects return to the original branch and recompile and run，
Up to now, the image in the MCU is called app_first, and then update the app_new directly (the image saved in step 4.3)
Then app_new can not boot successfully
That's awesome,
I tried the method you provided and it solved the problem, thank you very much.
I still have one more question I would like to continue to ask,
When I didn't add two statements into else, why is the damage to the hse_fw irreversible,
At this time I didn't make any changes to the HSE_FW and key catlog,
when I reset again, it should jump directly to the app, which is the normal logic,
The actual phenomenon is that the MCU can never return to normal.
You can see this permanent destruction after making the following modifications,
Hello @luhaiou_autolink,
I realized that you configured int_flash area to overlap the int_flash_cmac_tag area in your application and maybe the cmac tag area can be modified.
You have to ensure that there are no areas that can overlap and can modify cmac_tag area.
Best regards,
Dan
Thank you for your reply to my queries,
int_flash_cmac_tag is not overlap,
We can confirm the file from cl_factory_s32k312_hse_app0_blinky.hex in new branch
1.I would like to ask you to confirm that when using Advance secure boot, when the app is updated, the user will have to reinstall the SMR in order to store the new auth-proof to HSE Secure NVM.
May be auth-proof is stored directly in the HSE Secure NVM instead of storing the proof address in the codeflash.
This may be the functional feature of ASB mode?
hello .@dan
Thank you for your long support,
The reason for the Secure Boot failure after updating the app has been found,
the last step , When installing the new_app, the entire chip is wiped and the IVT area is also erased,
so boot fail !
Now there is only one problem left unsolved,This issue still needs your help
Hello @luhaiou_autolink,
I checked this situation and I detected that the CMAC tag value has not been updated yet at the address 0x584000.
Pass:
Fail:
Best regards,
Dan
