This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU Service with readback protection

Can DFU Service update the SoftDevice, Application, and/or Bootloader if readback protection is set to ALL?

Parents
  • 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.

Reply
  • 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.

Children
  • 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.

    1. If I do not write CLENR0, and I write 0xFFFF00FF to RBPCONF, can a SWD read anything from the device? (YES,NO)

    2. 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)

    Thanks for your help.

  • Thats what my reading of that table says. PALL is on, Code0 protect is off and everything is Region 0 because you haven't defined CLENR0. That prevents any SWD access of anything but allows all your code to read and write all your code and RAM space.

  • The way I interpret the table is that everything (SD, App, BL) is in region 1 not region 0. If CLENR0 is not written then Region 0 Size = 0, and then Region 1 would have to be whats left, which is the entire ROM code memory.

    Let UICR.RBPCONF.PALL = 0x00 Let UICR.RBPCONF.PRO = 0xFF

    According to Table 40 in section 9.1.3: If a SWD attempts to access region 1 then all regions are NA0 (Good).

    If code in region 1 (i.e. DFU bootloader) requests access then the code/ram region 0 = Limited Access. Since all code is in region 1 then this doesn't matter if my understanding above is correct.

    If code in region 1 (i.e. DFU bootloader) requests access then the code/ram region 1 = Full Access. This is good because the SoftDevice, Application, and Bootloader are all in Region 1 if my understanding is correct.

Related