STM32 security in practice workshop: Do you have code examples for the G4 with dual bank architecture?

[Anguel]

Hi,

I am currently going through the "STM32 security in practice workshop" which is for the G0 and I really like it.

1. Now my target is a G4 with dual bank. So I wonder if you have some code for this MCU as it probably needs some more settings to add because of its 2 banks. Or does the HAL refer to bank 1 (where the bootloader is) anyway by default? I do NOT need 2 images, just to handle the dual-bank design properly when adding the protections.
2. You don't set the secure memory area in code in the workshop. Is there any special reason for this and can this be done from code?
3. And what is actually the difference between the code presented in the workshop and the X-CUBE-SBSFU. Which is recommended to use? I find the practice workshop easier to understand and implement than the SBSFU. Additionally, SBSFU projects do not seem to be based on CubeMX (.ioc) and therefore don't offer easy implementation of modern bootloaders using FD-CAN or similar as far as I understand.

Thanks,

Anguel

[Jocelyn RICARD · Accepted solution]

Hello Anguel,

The goal of this MOOC is to understand the concepts.

The code provided can be reused and adapted, you just need to adapt the flash driver.

Reason why secure memory is not activated is that it requires a bit more expertise to avoid bricking the device.

More dedicated video may come to explain in detail how it works and how it should be properly setup.

Regarding your last question, as I said, the MOOC is here to explain the principles.

The SBSFU is a complete solution including all the mechanisms needed to perform a secure firmware update.

So, once you have understood the basic principles, you can switch to SBSFU or use any secure boot, secure firmware update on the market.

SBSFU is not based on CubeMX. This would require a very heavy work and maintenance. This is not planned.

You can use STM32CubeMX to build and test your bootloader.

Then once it is working fine, you will have to integrate it into SBSFU or in your application depending on your setup.

I hope this answers your questions.

Best regards

Jocelyn

[Anguel]

Hi Jocelyn,

Thanks for your answer. As far as I understood using Bootlock + RDP1 + Secure Memory + WRP is enough in most cases to reach a good level of protection on the STM32Gx series, so if that works ok I probably won't need the complex SBSFU framework.

It is interesting that you say bricking the device is possible with secure memory settings. Does this also apply when in RDP1 on the STM32Gx? The workshop does not mention such thing and I thought that I can always go back to RDP0 if something goes wrong. But maybe this is not the case?

Thanks,

Anguel

[Anguel]

A short update:

When you say "bricking the device" you are probably referring to the problem described here: https://youtu.be/MC1N6uZepGo?t=222

However this seems to not only apply to G0 as mentioned in the presentation but also to G4! According to the G4 manual:

Caution: If BOOT_LOCK is set in association with RDP Level 1, the debug

capabilities of the device are stopped and the reset value of the

DBG_SWEN bit of the FLASH_ACR register becomes zero. If the

DBG_SWEN bit is not set by the application code after reset, there is

no way to recover from this situation.

As far as I understand setting DBG_SWEN=1 right before jumping to the application is what must be done.

Now I looked at the MOOC security in practice workshop code and the SBSFU code and I don't see any code that reenables the debugger before leaving secure memory. Did I overlook something or why is this?

Thanks in advance,

Anguel

[Jocelyn RICARD]

Hi Anguel,

yes, this is the point.

The STM32G0 and STM32G4 have this important security feature that gives the ability to lock the JTAG in RDP1 which is very powerful but needs to be fully understood during development to avoid bricking the device. This is the reason why this is not activated in such video.

Also, in SBSFU, the point is to protect the device, so no enabling of the debug by default.

In practice, as long as you can update the firmware with the secure boot, the new firmware can re-enable the JTAG, or application can implement a specific authentication check to re-enable it.

I hope this answers to your question

Best regards

Jocelyn

[Anguel]

Hi Jocelyn,

now I tested everything so far, enabled WRP + SECMEM + BOOTLOCK + RDP1 and they work fine.

As you proposed, I added a special command in the application to reenable the debugger to prevent bricking. It enables the debugger only when this command is sent to the application.

But now I am really confused, because RDP1 + BOOTLOCK don't disable the debugger at all. I can still connect to the G4 using STM32CubeProgrammer and can regress to RDP0 without sending my special command to the application. How is that possible? I am working with a NUCLEO-G474RE board.

UPDATE: Some more information. It looks like with RDP1+BOOTLOCK if I connect with the programmer, the program hangs, even a board reset through the black button is not possible anymore, but I can still change RDP1 back to RDP0. Was there maybe a change in G4 behavior to prevent bricking the device? If I remember, before enabling bootlock I could not connect to the debugger at all when I disable it via HAL_FLASHEx_DisableDebugger(), it simply did not find the device. But now with bootlock it connects but the software hangs. Is this expected?

Regards,

Anguel

[Jocelyn RICARD]

Hi Anguel,

Well, I need to check on my side.

Didn't use the G4 yet.

I'll tell you what I have found.

Best regards

Jocelyn

[Anguel]

Many thanks in advance, I am looking forward to your tests.

[Jocelyn RICARD]

Hello Anguel,

I could reproduce the issue. The setting of bootlock + secure memory + RDP1 Level one does not disable the jtag access as this is done on STM32G0.

The reference manual will be changed.

The fact the program hangs when you connect the debugger is normal. The STM32 considers this as an intrusion and then puts CPU in stall.

Best regards

Jocelyn

[Anguel]

Hello Jocelyn,

Big thanks for the confirmation. I really hope that this is "by design" and not a bug.

Best regards,

Anguel