RDP & Bootloader: Cannot be used together?

[Goof Ball]

I have an STM32F405 (which has no PCROP). I want RDP Level 1, but also want to re-flash firmware updates using the bootloader (and the DeFuse utility).

With RDP Level 0: everything works: I can reflash firmware updates, no problem.

But when optionBits are set to RDP Level1: to quote @andy​ (from here: https://bit.ly/2DfaUjf :(

It appears that the bootloader doesn't support any Flash writes until the read protection has been removed, and this involves erasing the entire Flash (OK) and then rebooting (not OK!). Rebooting the CPU exits the bootloader, leaving it with no firmware and BOOT[1..0] = 00.
 
In other words, bricked.

Any ideas how to get the bootloader to reflash, yet have RDP level 1 ?

[Tesla DeLorean]

If you've tied BOOT0 LOW it might be a challenge, most people don't do that. Normally you'd boot with BOOT0 HIGH, mass erase the part, and then update.

In order to secure your product you're expected to write your own loader, supporting the protocols and memory protection you need.

[TDK]

You can still connect to it with SWD to recover.

> Any ideas how to get the bootloader to reflash, yet have RDP level 1?

Not with BOOT0 tied to GND, unless you have your own bootloader.

[Goof Ball]

Thanks @Community member​  and @TDK​ ...

My BOOT0 is tied to GND. So how about this: RDP is Level1:

1) My firmware waits for the secret buttonpress combo (or whatever), signifying that we are doing a firmware upgrade.

2) My firmware copies part of itself to SRAM

3) My firmware Jumps to execute from SRAM

4) SRAM firmware changes RDP to Level 0. This causes mass erase.

5) SRAM firmware waits for mass erase to finish, then writes the following to flash 0x0800 0000: JMP to 0x1FFF 0000 (bootloader location on my 32F405)

6) SRAM firmware reboots, cpu executes from flash (cuz BOOT0 = 0), but immediately jmps to bootloader.

I realize the interrupt table and functions get nuked by the mass erase... so that will be fun.

And my other worry is whether 5) can be done (the datasheet talks about having to reboot for the new RDP value to "take")

Any more guidance would be greatly appreciated.

[Tesla DeLorean]

Well I'm pretty sure you don't need to mass erase the part for you to erase and write things yourself.

The trick here is to never erase the front blocks at 0x08000000 that represent your loader, you write your application into memory deeper into the flash, and your loader only jumps there if the image is complete, and can be authenticated. If this has some robustness you'd use some asymmetric elliptic curve signing, but at the very least a CRC or salted-SHA.

One of the top rules of Fight Club is to never give your adversary access to plain text object code. If you use the ROM based system loader via UART or USB, you pretty much have zero protection.

[Piranha]

In addition to what Clive said, you forgot the point 4a - the power cuts off and the device is bricked.

[Goof Ball]

@Community member​  said: "I'm pretty sure you don't need to mass erase the part ".... I think this is done automatically in the hardware whenever RDP transitions from Level 1 to 0... which makes sense - Level 0 is no protection at all, so mass erase has to be done before entering Level0

[Tesla DeLorean]

But you need to change the RDP level why exactly?

[Goof Ball]

I hear ya. I find it to be especially a problem when deFuse starts nuking flash immediately upon USB plugin, but ****** the User is still fumbling around trying to fully insert the USB plug.

[Goof Ball]

What the frog? They filter out the word "B00zer". Totally Lame.