How can we configure SECURITY Mode for STM32H753

[SPati.7]

Do we have provision to configure STM32H753 as Secure Mode or not using SECURITY Pin in Boot selection ??

or is this completely owned by STM ??

is Devices received with enabling SECURE MODE it self ?? as mentioned in below Diagram ??

 

is STM does this SECURITY Bit Enabled in manufacturing itself ??

[Fred]

Hello,

I am not sure to get the question right.

But if your point is about how to configure the security bit in STM32H753, this is something you can do programmaticaly as shown in X-CUBE-SBSFU:

  /* Set the security bit if needed */

  /* ------------------------------ */

  if ((psFlashOptionBytes->USERConfig & FLASH_OPTSR_SECURITY) == RESET)

  {

   psFlashOptionBytes->Banks = FLASH_BANK_1;

   psFlashOptionBytes->OptionType = OPTIONBYTE_USER;

   psFlashOptionBytes->USERType = OB_USER_SECURITY;

   psFlashOptionBytes->USERConfig = OB_SECURITY_ENABLE;

   if (HAL_FLASHEx_OBProgram(psFlashOptionBytes) == HAL_OK)

   {

    TRACE("\r\n\t Security bit set.");

    /*

     * We need to reload the OBs before configuring the secure user memory area,

     * otherwise the configuration is skipped because Secure Mode is not entered at reset (not booting in RSS).

     *

     * Note: updating pbIsProtectionToBeApplied and e_ret_status would be useless here.

     */

    HAL_FLASH_OB_Launch();

   }

   else

   {

#if defined(SFU_VERBOSE_DEBUG_MODE)

    TRACE("\r\n\t Cannot set the security bit - ERROR");

#endif /* SFU_VERBOSE_DEBUG_MODE */

    return (SFU_ERROR);

   }

You can also probably do this with the latest versions of Cube programmer (was not possible initially but should have been fixed).

Is it what you were looking for ?

[SPati.7]

Yes @Fred​  I am looking for these details only.

Who is owning on enabling Secure Mode for STM32MCU, Now it is clear that as part of SBSFU, we are enabling it.

[Fred]

Ok, I see.

Generally speaking, the Option Bytes settings are part of the user's choices when going into production.

Here is how things have been thought for X-CUBE-SBSFU

1. To ease the life of developers, we wanted the possibility for SBSFU to do some "auto-configuration" of the Option Bytes.

So, in app_sfu.h, the developer can choose the protection he wants to apply, and this can impact the Option Bytes (but not only this).

This way, when you recompile and flash your code at development stage, the OBs are set by the software, you do not need to care for Cube programmer and you save time.

2. When the development phase is over, so when you are happy with your SBSFU software, we expect that the customer will

• use whatever he wants to configure the OBs on the production line
• flash a SBSFU software that will only check that the OBs configuration is as expected

This is controlled thanks to 2 compiler switches in app_sfu.h:

/**

 * The define below (SECBOOT_OB_DEV_MODE) determines if the OPTION BYTES should be handled in Development mode or not.

 * This define is taken into account only if RDP level 2 is not set.

 * If RDP level 2 is set no modification can be done anyway.

 *

 * Enabled: Option Bytes Development Mode enabled.

 *     SB_SFU uses a "check and apply" strategy when checking the Option Bytes configuration.

 *     If an OB is not set though it should be then this setting is automatically corrected.

 *     This applies only as long as RDP level 2 is not set.

 *

 * Disabled: Option Bytes Development Mode disabled.

 *      In this mode the Option Bytes are supposed to be already configured properly when the software starts for

       the first time.

 *      SB_SFU checks the Option Bytes configuration but does not correct it.

 *      If a problem is detected an error message is reported and the execution stops.

 */

#define SECBOOT_OB_DEV_MODE

So our vision was really to have 2 modes:

• dev mode ==> SBSFU can configure the OBs
• production mode ==> the OBs must be configured by a script or whatever on the production line and when SBSFU is flashed and starts, it only checks that the configuration is correct

[SPati.7]

@Fred​  Thanks for your quick reply.

From above it is understood that, SBSFU will apply OB, only in Development Mode configuration.

For Production Mode, can't we do with SBSFU application itself ?? or only we have to run Script or Some Procedure to configure through CubeProgrammer in Manufacturing site only ??

Option Bytes include all Settings like SECURITY_ENABLE, SECURE_MEMORY, PCROP, WRP etc.

[Fred]

This point is really your choice, you may decide that even in production mode SBSFU will configure the OBs.

Nevertheless, please keep in mind that to have a good security level we highly recommend using RDP Level 2. When RDP level 2is enabled, the Option Bytes cannot be modified.

So, if you want SBSFU to configure the OBs even in production mode then you need to use RDP-level1 only but this opens the door to attacks. For instance, an attacker might trigger an RDP regression and wipe your FLASH. Thus, a denial of service attack succeeds.

[Fred]

Should be this bit with Cube programmer:

[SPati.7]

Thank You @Fred​ . this i was aware, But through SBSFU application itself, i thought we can do.

So to achieve RDP LVL 2, we have to give Manufacturing instructions to enable Option Bytes for Production Mode. This is only Best option i believe.

[Fred]

Yes, I have no experience with the production aspects but several production programming solutions for STM32 exist (maybe you can get in touch with your local sales office).