menu "Application Rollback" config BOOTLOADER_APP_ROLLBACK bool "Enable application rollback" default y help After an OTA update, the bootloader starts the new application in the ESP_OTA_IMG_PENDING_VERIFY state. If the application resets, crashes, or loses power before being confirmed valid, the bootloader marks it as aborted on the next boot and selects the previously working application instead. Disabling this option removes the automatic recovery path after a failed OTA update: a failed update can leave the device with an unbootable application. choice BOOTLOADER_APP_ROLLBACK_CONFIRM_MODE prompt "Rollback confirmation checkpoint" depends on BOOTLOADER_APP_ROLLBACK default BOOTLOADER_APP_ROLLBACK_CONFIRM_ON_STARTUP config BOOTLOADER_APP_ROLLBACK_CONFIRM_ON_STARTUP bool "Confirm app automatically during system startup" help The application is marked valid near the end of system startup, immediately before app_main is called. Reaching app_main is treated as a successful boot; this confirms IDF startup completed but does not verify application-specific functionality. Since the state is already ESP_OTA_IMG_VALID by the time app_main runs, application code cannot use esp_ota_get_state_partition() to detect the first boot of a new application. config BOOTLOADER_APP_ROLLBACK_CONFIRM_BY_APP bool "Application decides the confirmation checkpoint" help The application must confirm itself valid during its first boot by calling esp_ota_mark_app_valid_cancel_rollback(), or reject the update with esp_ota_mark_app_invalid_rollback_and_reboot(). If neither is called before a reset, the bootloader marks the app as aborted and rolls back to the previous working application. Rollback is possible only between apps with the same security version. endchoice config BOOTLOADER_APP_ANTI_ROLLBACK bool "Enable app anti-rollback support" depends on BOOTLOADER_APP_ROLLBACK_CONFIRM_BY_APP default n help This option prevents rollback to previous firmware/application image with lower security version. config BOOTLOADER_APP_SECURE_VERSION int "eFuse secure version of app" depends on BOOTLOADER_APP_ANTI_ROLLBACK default 0 help The secure version is the sequence number stored in the header of each firmware. The security version is set in the bootloader, version is recorded in the eFuse field as the number of set ones. The allocated number of bits in the efuse field for storing the security version is limited (see BOOTLOADER_APP_SEC_VER_SIZE_EFUSE_FIELD option). Bootloader: When bootloader selects an app to boot, an app is selected that has a security version greater or equal that recorded in eFuse field. The app is booted with a higher (or equal) secure version. The security version is worth increasing if in previous versions there is a significant vulnerability and their use is not acceptable. Your partition table should has a scheme with ota_0 + ota_1 (without factory). config BOOTLOADER_APP_SEC_VER_SIZE_EFUSE_FIELD int "Size of the efuse secure version field" depends on BOOTLOADER_APP_ANTI_ROLLBACK range 1 32 if IDF_TARGET_ESP32 default 32 if IDF_TARGET_ESP32 range 1 4 if IDF_TARGET_ESP32C2 default 4 if IDF_TARGET_ESP32C2 range 1 9 if IDF_TARGET_ESP32C5 default 9 if IDF_TARGET_ESP32C5 range 1 16 default 16 help The size of the efuse secure version field. Its length is limited to 32 bits for ESP32, 4 bits for ESP32-C2, 9 bits for ESP32-C5, and 16 bits for other targets. This determines how many times the security version can be increased. config BOOTLOADER_EFUSE_SECURE_VERSION_EMULATE bool "Emulate operations with efuse secure version(only test)" default n depends on BOOTLOADER_APP_ANTI_ROLLBACK select EFUSE_VIRTUAL select EFUSE_VIRTUAL_KEEP_IN_FLASH help This option allows to emulate read/write operations with all eFuses and efuse secure version. It allows to test anti-rollback implementation without permanent write eFuse bits. There should be an entry in partition table with following details: `emul_efuse, data, efuse, , 0x2000`. This option enables: EFUSE_VIRTUAL and EFUSE_VIRTUAL_KEEP_IN_FLASH. endmenu