This commit fixes the issue when trying to allocate memory
with the MALLOC_CAP_EXEC in RTC memory. Prior to the fix,
the heap allocator was returning an address in RTC DRAM.
To fix this issue:
- modified memory_layout.c of the concerned targets to fill the iram_address
field in the rtc entry of the soc_memory_region array properly.
- modified heap component related functions to return IRAM address when
an allocation in RTC memory with MALLOC_CAP_EXEC is requested.
Closes https://github.com/espressif/esp-idf/issues/14835
For the SoCs that support configurable MMU page size, it is possible
that the bootloader and application are built with different MMU page
size configuration. This mismatch is not supported at the moment and
application verification fails (at bootup or during OTA update).
Configuring MMU page size helps to optimize the flash space by having
smaller alignment and padding (secure) requirements. Please note that
the MMU page size is tied with the flash size configuration at the
moment (`ESPTOOLPY_FLASHSIZE_XMB`).
This MR ensures that application verification happens using the MMU page
size configured in its binary header. Thus, bootloader and application
can now have different MMU page sizes and different combinations shall
be supported.
Added explicit wait for key manager state to be idle before configuring
the register for flash encryption key usage from efuse. This now ensures
that flash contents are encrypted using efuse programmed key.
Also refactored code a bit to move into target specific directory.
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.
Many places in the ESP_SYSTEM are using CONFIG_FREERTOS_UNICORE instead of CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE (GitHub PR)
Closes IDFGH-11333
See merge request espressif/esp-idf!27435
Added an API to verify the bootloader and app image before revoking the key in Secure Boot V2.
This will help in preventing the device to be bricked if the bootloader/application cannot be
verified by any other keys in efuse
Since DRAM and IRAM are superposed on esp32c6 it is not necessary to convert a freshly allocated
DRAM addr to its IRAM equivalent when MALLOC_CAP_EXEC is passed to heap_caps_malloc(). Instead,
proceed with a default allocation since the address returned by multi_heap_malloc() already belongs
to the IRAM region.
Applies for esp32c6 and every boards with superposed DRAM and IRAM addresses.
User's custom data are not taken into account during the CRC calculation anymore.
Which means taht the retained mem structure is not systematically erased
on each reboot anymore.
