NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2

[gorazd]

Hi, what are the (security) implications of running bootloader with #define NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 1 in production code?

We use sdk15.0.0 with secure dfu. We are not planning to update softdevice nor bootloader to our product at any point. Updating application could happen though over nrf connect app.

We know that NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 == 0 enables bootloader to check the application's CRC. But in the worst case (crc does not match) we can just update the firmware again over nrf connect app. Is there anything else we should be worried about?

[Einar Thorsrud]

Hi,

Is there anything else we should be worried about?

I would say no. It depends on your level of paranoia, but I do not see any practical issues with skipping CRC check of the application. In the case of a general flash corruption (highly unlikely), the affected part could just as well be the MBR or bootloader, and in that case, the device will be bricked. The only situation where the application only is affected is typical if you have a bug in your application that causes it to erase or overwrite parts of its own flash. And this is also pretty far fetched, and not something you need to consider for most applications.

[gorazd]

> I do not see any practical issues with skipping CRC check

by skipping the crc our production code is closer to our developing environment (e.g. we dont need bootloader_settings page) which means easier (process of) testing, debugging and maintaining of our code

> depends on your level of paranoia

we are already using the read back protection mechanism in our firmware, so this app crc check seems more like a belt and suspenders thing when it comes to integrity of the firmware / tampering