Previous method was to write-protect this efuse, however on ECO3
the write protect field also covers the UART_DOWNLOAD_DIS efuse.
Doing it this way keeps the possibility of disabling UART download
mode, later.
In commit 02d2903e39, mbedtls was
updated to release v2.16.5, where it was made mandatory to initialize
mbedtls_ctr_drbg_context before using same. It was fixed in wpa supplicant
but missed out in secure boot v2 verification code. This commit
fixes that.
Goal is that multiple faults would be required to bypass a boot-time signature check.
- Also strengthens some address range checks for safe app memory addresses
- Change pre-enable logic to also check the bootloader signature before enabling SBV2 on ESP32
Add some additional checks for invalid sections:
- Sections only partially in DRAM or IRAM are invalid
- If a section is in D/IRAM, allow the possibility only some is in D/IRAM
- Only pass sections that are entirely in the same type of RTC memory region
* Don't bother checking the chip revision if it looks like the partition
doesn't really contain an app
* Don't print the "info" level about the revision & min revision unless
we're in the bootloader (otherwise it gets printed at random times
during the OTA process)
bootloader_random_enable() and bootloader_random_disable() functions
can be used in app.
This MR added the protection for shared CLK_EN and RST_EN registers.
and all ECDSA to be disabled if secure boot is not enabled
Previously if ECDSA disabled in config then secure_boot_signatures.c would
fail to build (whether or not secure boot was enabled).
To avoid breaking apps that might be using the signature scheme with custom OTA
without enabling secure boot signatures in config, this change just disables
this functionality if unavailable in mbedTLS config.
Possible fix for root cause of https://github.com/espressif/esp-idf/pull/3703
Commit 8cd04c80 has added a dependency of efuse component on
esp_clk_apb_freq, however there was no definition of this function in
the bootloader context.
Reported at https://esp32.com/viewtopic.php?f=13&t=12035
This saves time when waking up from deep sleep, but potentially decreases
the security of the system. If the application able to modify itself
(especially areas that are loaded into RAM) in flash while running
without crashing or is modifies the cached bits of information about
what was last booted from the bootloader, this could cause security
issues if the user does a "deep sleep reset" since the full validation
is skipped.
Signed-off-by: Tim Nordell <tim.nordell@nimbelink.com>
No need to take this step if we are not doing image validation. The
obfuscation only buys us a tiny bit of "security" anyways since the
main parts of flash are memory mapped, too. This saves a little bit of
wake-up time when waking up from deep sleep when the
BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP option is set.
Signed-off-by: Tim Nordell <tim.nordell@nimbelink.com>
