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.
sizeof(time_t) was previously switched from 4 to 8, ROM functions that use
time_t or dependent types (such as "struct stat") are no longer called due as
they still treat sizeof(time_t) as 4 (see commit
24c20d188e).
However, there is a ROM callpath that was left out. If putchar is the first
stdio print related call, the call path will result in cantwrite() ->
__swsetup_r() -> __smakebuf_r() -> __swhatbuf_r() using the ROM "struct stat"
(where sizeof(time_t)==4).
Instead of removing all printf related ROM newlib functions (which will result
in increased binary size), this commit adds a workaround to setup the stdio
files before any print related calls occur.
This results in cantwrite() always returning false, thus the callpath described
above never being reached.
Closes https://github.com/espressif/esp-idf/issues/9269
Functions used for burning this efuse would log, but at this point
esp_log is not initialized. Moved to a later point in the startup process.
Closes https://github.com/espressif/esp-idf/issues/9457
This commit marks all functions in interrupt_controller_hal.h, cpu_ll.h and cpu_hal.h as deprecated.
Users should use functions from esp_cpu.h instead.
* Some components have initialization dependencies. To account for
them, simple numeric priority values are introduced.
* esp_system_init_fn_array moved into Flash from DRAM
* System init functions defined using ESP_SYSTEM_INIT_FN now return
an error code. This enables simpler and more consistent error
handling in the init functions. Returning an error from an init
function is now a valid approach — the startup code will print
an error and abort.
Moved the following kconfig options out of the target component:
* ESP32_X_BROWNOUT_* -> esp_system
* ESP32_X_DEBUG_OCDAWARE -> esp_system
* APP_NO_BLOBS -> build type (main kconfig)
* This function has been accidentally removed.
It is necessary to provide the emergency
exception memory pool size for C++ code.
Since our libstdc++ always has exceptions
enabled, this function must exist here even if
-fno-exception is set for user code.
As this mode uses the public keys attached to the existing app's signatures to
verify the next app, checking that a signature block is found on boot prevents
the possibility of deploying a non-updatable device from the factory.
