This commit deprecates the "freertos/xtensa_context.h" and "xtensa/xtensa_context.h"
include paths. Users should use "xtensa_context.h" instead.
- Replace legacy include paths
- Removed some unnecessary includes of "xtensa_api.h"
- Add warning to compatibility header
This commit deprecates the "freertos/xtensa_api.h" and "xtensa/xtensa_api.h"
include paths. Users should use "xtensa_api.h" instead.
- Replace legacy include paths
- Removed some unnecessary includes of "xtensa_api.h"
- Replaced some calls with "esp_cpu_..." equivalents
- Add warning to compatibility header
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.
This commit mainly targets the ESP32-P4. It adds supports for coprocessors on
RISC-V based targets. The coprocessor save area, describing the used coprocessors
is stored at the end of the stack of each task (highest address) whereas each
coprocessor save area is allocated at the beginning of the task (lowest address).
The context of each coprocessor is saved lazily, by the task that want to use it.
Task snapshot API were never intended to be called from user code. This commit
makes task snapshot a private API thus moves `#include "freertos/task_snapshot.h"`
to `#include "esp_private/freertos_debug.h"`.
Task snapshot related Kconfig options have also been hidden.
Note: Added 'freertos_common' mapping to ldgen mapping execptions lists due to
inlining of 'freertos_debug.h' functions.
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.
