Prior to this commit, esp_efuse_check_errors() is only called when it's
2nd stage btld app.
This commit moves this error check so under all conditions (including
ram app, pure ram app) will check this efuse error
Some additional checks related to secure version of the application in
anti-rollback case have been added to avoid any attempts to boot lower
security version but valid application (e.g., passive partition image).
- Read secure_version under sha256 protection
- First check has been added in the bootloader to ensure correct secure
version after application verification and loading stage. This check
happens before setting up the flash cache mapping and handling over
the final control to application. This check ensures that application
was not swapped (e.g., to lower security version but valid image) just
before the load stage in bootloader.
- Second check has been added in the application startup code to ensure
that currently booting app has higher security version than the one
programmed in the eFuse for anti-rollback scenario. This will ensure
that only the legit application boots-up on the device for
anti-rollback case.
In ESP32-H2, the ECDSA peripheral by default uses the TRNG (hardware)
generated k value but it can be overridden to software supplied k.
This can happen through by overriding the `ECDSA_SOFTWARE_SET_K` bit
in the configuration register. Even though the HAL API is not exposed
for this but still it could be achieved by direct register
programming. And for this scenario, if sufficiently random k is not
supplied by the software then it could posses a security risk.
In this change, we are unconditionally programming the efuse
`ESP_EFUSE_ECDSA_FORCE_USE_HARDWARE_K` bit during startup security
checks itself. Additionally, same is ensured in the `esp_efuse_write_key`
API as well. This always enforces the hardware k mode in the ECDSA
peripheral and ensures strongest possible security.
For cases where the bootloader is not enabled with the security features
ends up receiving an incorrect application with flash encryption enabled
should not really program any security efuses.
In the startup sequence, we first used to program the ROM DL mode
configuration but now we check for the flash encryption related checks
first. If the flash encryption related checks finds that flash
encryption is not enabled on the device then it aborts the boot process.
This is the case with `CONFIG_SECURE_FLASH_CHECK_ENC_EN_IN_APP` enabled.
This would at-least ensure that accidental program of security enabled
application does not really program any ROM DL mode efuses and there is
chance to recover the device.
