No the DFU service won't be able to update anything in region 0 if region 0 is defined, ie CLENR0 is set to something other than the default. If you look at the table in the MPU chapter you'll see that ALL has more to do with debugger access to data, code in region 1 can't read or write to the code space in region 0 in any case where CLENR0 is defined.
This is why, since the advent of the Master Boot Record and basic support for DFU, loading the softdevice no-longer sets CLENR0. I think the nRF52 does away with all the region0/region1 stuff and protection is limited to turning the debugger access off.
It's not clear why a readback protection would prevent you from writing? If you could write to region 0 you could clear one page in region 0, write a tiny piece of code to it which dumps the rest of the pages you didn't clear to wherever you like and hence subvert much of the read protection.
I have some follow up question just to make sure that I am fully understanding this correctly. I need to ensure our firmware is protected from security threats such as SWD flash downloads if we enable the BLE DFU Service.
If I do not write CLENR0, and I write 0xFFFF00FF to RBPCONF, can a SWD read anything from the device? (YES,NO)
If I do not write CLENR0, and I write 0xFFFF00FF to RBPCONF, can the DFU Service update the SoftDevice, Application, and/or Bootloader per the SDK documentation? (YES,NO)
I have some follow up question just to make sure that I am fully understanding this correctly. I need to ensure our firmware is protected from security threats such as SWD flash downloads if we enable the BLE DFU Service.
If I do not write CLENR0, and I write 0xFFFF00FF to RBPCONF, can a SWD read anything from the device? (YES,NO)
If I do not write CLENR0, and I write 0xFFFF00FF to RBPCONF, can the DFU Service update the SoftDevice, Application, and/or Bootloader per the SDK documentation? (YES,NO)
