Firmware MPU configuration and SBSFU FPU exceptions

[sute]

It seems to be a recurring challenge in the community posts of getting firmware MPU configuration to work with SBSFU. We also had the problem of application firmware hanging when running it with SBSFU. A solution of clearing floating point unit flags was found from a post here: https://community.st.com/t5/stm32-mcus-security/ethernet-init-fail-with-sbsfu-bootloader/td-p/211911/page/2:

 // Clear Floating point Unit flags
  {
	  register uint32_t fpscr_val = 0;
	  fpscr_val = __get_FPSCR();
	  fpscr_val &= (uint32_t)~0x8F; // Clear all exception flags
	  __set_FPSCR(fpscr_val);
  }

My question is: Why are the exception flags set after running SBSFU and should I be concerned by that?

[Jocelyn RICARD]

Hello @sute,

I'm not sure to get your point.

Exceptions are always active and you may need to handle them.

The fact that an exception occurs after running SBSFU, with this VFP for instance, is not normal in general.

If you get a MPU exception, you need to understand why and fix it.

Yes MPU is complex to handle. Its main purpose is internal isolation. It has to follow the mapping changes.

The MPU is useful if an attacker manages to perform a remote attack on your MCU, using a stack overflow and other technics going through your communication protocol. In that case, the content of internal assets are easier to extract. Now, you still have the secure boot checking application authenticity that cannot be by-passed.

Best regards

Jocelyn  

[sute]

Hi thanks for the response. What I am wondering is why SBFSU is causing an FPU exception. Is it expected behavior from SBSFU since you suggested clearing the flags at the start of the application? I have not yet had the chance to investigate further what exception was triggered but should I be worried that SBSFU is not working properly?

[Jocelyn RICARD]

Hi @sute ,

I gave the explanation of such behaviour in the link you provided:

"It is possible to have an exception is a FPU register previously accessed in non privileged mode in now accessed in privileged mode."

The SBSFU uses privilege/non privileged states of the Cortex to improve isolation between secure boot parts that are dealing with keys (privileged) from parts that do not contains secret assets and that may be connected to outside.

When secure boot has finished all verifications and jumps into the application it must do this in privileged mode so that application can make all needed initializations. 

The SBSFU should launch the application after cleaning every thing so that application can run as if it was launched directly after reset (except for preset MPU configuration if you want to use it).

But there are some cases like this one that were not seen at SBSFU development and testing.

Best regards

Jocelyn

[sute]

Hi @Jocelyn RICARD, thanks I think I now have a more clear picture of what is happening. I think I misread your explanation in the other thread due to a typo. I understand that SBSFU is accessing the FPU in non-priviliged mode and accessing FPU in the user application in privileged mode causes an exception. What I am still struggling to understand is why clearing the FPU exception flags at the start of the user application, before FPU is accessed in privileged mode, solves the issue?

[Jocelyn RICARD]

Hello @sute ,

I don't know. Normally exception flags are used once an exception is raised to know the origin. Here this seems different. To be investigated 🙂

Best regards

Jocelyn