SWD Enabled.

[sn00pster]

When encryption is enabled and we’re in ROP1 it would probably be a good idea to reconfigure SWD pins to disable them while uploading firmware.

Theres a potential vector here in that I believe that even with ROP1 enabled RAM can be read and written to. It cannot be completely mitigated against because I believe that a “bad actor” could inject breakpoints and step over the code which disables SWD, but I think it’s worth considering. There may be other ways of mitigating security issues.

[dmitrystu]

Yes. I will add this option. Usually, ROP1 is used for testing to avoid irreversible chip locking. For production, ROP2 can be used.

[sn00pster]

There's a very good document by ST on this subject:

https://www.st.com/content/ccc/resource/technical/document/application_note/group1/9f/0b/e4/b6/75/15/4f/e2/DM00493651/files/DM00493651.pdf/jcr:content/translations/en.DM00493651.pdf

Particularly of interest is the Firewall on the L0 and L4 processors.

[IvanShalnev]

Also came to the enabled SWD issue.

The idea was to put a jumper on the SWD header pins to activate bootloader. PA13 and PA14 are mapped to SWD by default so pull-up/pull-down resistors are not configured during bootstrap. SWD disabling allows to use PA13/PA14 for bootstrap.

Attached stm32f103.s solves the issue with PA13/PA14.
stm32f103.S.txt

[dmitrystu]

@IvanShalnev Actually you can use both PA13 and PA14 as bootstrap pins with the following limitations. PA13 is active low (pulled high) and PA14 is active high (pulled low).
Anyway, I started the new feature branch.