DFU Service with readback protection

RE: DFU Service with readback protection

Hung Bui — Fri, 18 Nov 2016 11:13:37 GMT

@Greg Lund: You are correct, if UICR.RBPCONF.PR0 is enabled, meaning readback protection for code region 0 only. The question was about UICR.RBPCONF.PALL, when code region 1 still have read access to region 0.

RE: DFU Service with readback protection

Greg Lund — Thu, 17 Nov 2016 16:46:13 GMT

The DFU example included in SDK 10 is indeed affected by the status of the readback protection settings if you have softdevice readback protection enabled. There are several instances where dfu code tries to directly read soft device memory areas.

Instance 1: (main.c lines ~230 - 250)

if (dfu_start || (!bootloader_app_is_valid(DFU_BANK_0_REGION_START)))
{
    //nrf_gpio_pin_clear(UPDATE_IN_PROGRESS_LED);

    // Initiate an update of the firmware.
    err_code = bootloader_dfu_start();
    APP_ERROR_CHECK(err_code);

    //nrf_gpio_pin_set(UPDATE_IN_PROGRESS_LED);
}


if (bootloader_app_is_valid(DFU_BANK_0_REGION_START) && !bootloader_dfu_sd_in_progress())

DFU_BANK_0_REGION_START is a series of defines and macros that lead to checking a memory location within the soft device. This will cause the device to hard fault if readback protection is enabled.

I changed this to read NRF_UICR->CLENR0 to get the start address.

Instance 2: (dfu_init_template.c lines ~117 - 130)

// Third check: Check the array of supported SoftDevices by this application.
//              If the installed SoftDevice does not match any SoftDevice in the list then an
//              error is returned.
while (i < p_init_packet->softdevice_len)
{
    if (p_init_packet->softdevice[i]   == DFU_SOFTDEVICE_ANY ||
        p_init_packet->softdevice[i++] == SD_FWID_GET(MBR_SIZE))
    {
        return NRF_SUCCESS;
    }
}

// No matching SoftDevice found - Return NRF_ERROR_INVALID_DATA.
return NRF_ERROR_INVALID_DATA;

The macro SD_FWID_GET(MBR_SIZE) attempts to read from data within the softdevice. For lack of a better solution at this time, I have simply commented out this block of code and replaced it with

return NRF_SUCCESS;

RE: DFU Service with readback protection

Hung Bui — Mon, 18 Jan 2016 08:48:33 GMT

Hi Brett,

Read back protection has nothing to do with the DFU as the readback only protect the content of flash (code region 0 or all) from reading from the SWD interface. DFU on the other hand is the modification of the flash by the CPU (by the code in bootloader and the MBR).

If CLENR0 = 0xFFFFFFFF, it's interpreted as CLENR0 size = 0. Everything is Region 1.

When you set CLENR0, (e.g enable protection when flashing softdevice), it's still possible to update the softdevice (region 0) because the MBR is located inside region 0 and it's possible to modify code region 0 (but not changing the size of it).

RE: DFU Service with readback protection

Brett — Thu, 14 Jan 2016 04:08:37 GMT

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.

RE: DFU Service with readback protection

RK — Thu, 14 Jan 2016 02:52:15 GMT

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.

RE: DFU Service with readback protection

Brett — Thu, 14 Jan 2016 02:30:58 GMT

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)

Thanks for your help.

RE: DFU Service with readback protection

RK — Thu, 14 Jan 2016 00:46:20 GMT

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.

RE: DFU Service with readback protection

Brett — Wed, 13 Jan 2016 20:19:29 GMT

In the nRF51 Series Reference Manual Version 3.0, Section 8.1 it states...

"Code running from code region 1 will not be able to write to code region 0."

I'm assuming this means that only region 0 is protected. Since the bootloader for the DFU service is located in region 1 then I would assume the DFU Service would not work. I wanted to make sure, because it is not clear why a readback protection would prevent me from writing.