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>
We fixed some flash bugs in bootloader, but for the users used the old
vrsion bootloader, they can not fix these bugs via OTA, the solution is
add these updates in app startup.
These updates include:
1. SPI flash gpio matrix and drive strength configuration
2. SPI flash clock configuration
3. SPI flash read dummy configuration
4. SPI flash cs timing configuration
5. Update flash id of g_rom_flashchip
Made MMU pages available check in `esp_image_format.c`
This now makes it possible to map and process bootoader image as well in chunks when image doesn't fit completely into available free pages.
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
Do not include bootloader in flash target when secure boot is enabled.
Emit signing warning on all cases where signed apps are enabled (secure
boot and signed images)
Follow convention of capital letters for SECURE_BOOT_SIGNING_KEY variable, since it is
relevant to other components, not just bootloader.
Pass signing key and verification key via config, not requiring
bootloader to know parent app dir.
Misc. variables name corrections
Bootloader build requires verification key to be embedded in the binary.
Under specific configs, this key is generated during build time from the
signing key. Move the key generation to after the component
registration, since non scriptable commands are used in the process
(during early expansion)
This MR improves existing flash encryption document to provide simplified steps
Adds two new modes for user: Development & Release
Adds a simple example
Supports encrypted write through make command
Do not include bootloader in flash target when secure boot is enabled.
Emit signing warning on all cases where signed apps are enabled (secure
boot and signed images)
Follow convention of capital letters for SECURE_BOOT_SIGNING_KEY
variable, since it is
relevant to other components, not just bootloader.
Pass signing key and verification key via config, not requiring
bootloader to know parent app dir.
Misc. variables name corrections
!4452 and !4897 made some ill-advised corrections to dependency info;
revert those in this MR. Handling pre-built binaries as imported
libraries is retained, however.
Still using ESP32_xxx prefix on all chips: CORE_DUMP, APP_TRACE
Still using the same config prefix and duplicate names in esp32 & esp32s2beta: SPIRAM, PM
For example, if a renamed option CONFIG_NEW is a bool with value "n", kconfiglib will not generate a define for it in the Kconfig file. The define (#define CONFIG_NEW 1) will only be generated if the option is "y" or "m".
However the compatibility definition was always generated: #define CONFIG_OLD CONFIG_NEW. This broke the #ifdef checks which depended on the old option names.
Using xxx_periph.h in whole IDF instead of xxx_reg.h, xxx_struct.h, xxx_channel.h ... .
Cleaned up header files from unnecessary headers (releated to soc/... headers).
When flash work in DIO Mode, in order to ensure the fast read mode of flash
is a fixed value, we merged the mode bits into address part, and the fast
read mode value is 0 (the default value).
Fixed the case when the first part of log was missed
this was happened when:
* CONFIG_CONSOLE_UART_CUSTOM option is selected (UART1)
* The selected CONSOLE_UART port is used also for the console component
* in code esp_restart() or abort() functions were called.
This MR removes the common dependency from every IDF components to the SOC component.
Currently, in the ``idf_functions.cmake`` script, we include the header path of SOC component by default for all components.
But for better code organization (or maybe also benifits to the compiling speed), we may remove the dependency to SOC components for most components except the driver and kernel related components.
In CMAKE, we have two kinds of header visibilities (set by include path visibility):
(Assume component A --(depends on)--> B, B is the current component)
1. public (``COMPONENT_ADD_INCLUDEDIRS``): means this path is visible to other depending components (A) (visible to A and B)
2. private (``COMPONENT_PRIV_INCLUDEDIRS``): means this path is only visible to source files inside the component (visible to B only)
and we have two kinds of depending ways:
(Assume component A --(depends on)--> B --(depends on)--> C, B is the current component)
1. public (```COMPONENT_REQUIRES```): means B can access to public include path of C. All other components rely on you (A) will also be available for the public headers. (visible to A, B)
2. private (``COMPONENT_PRIV_REQUIRES``): means B can access to public include path of C, but don't propagate this relation to other components (A). (visible to B)
1. remove the common requirement in ``idf_functions.cmake``, this makes the SOC components invisible to all other components by default.
2. if a component (for example, DRIVER) really needs the dependency to SOC, add a private dependency to SOC for it.
3. some other components that don't really depends on the SOC may still meet some errors saying "can't find header soc/...", this is because it's depended component (DRIVER) incorrectly include the header of SOC in its public headers. Moving all this kind of #include into source files, or private headers
4. Fix the include requirements for some file which miss sufficient #include directives. (Previously they include some headers by the long long long header include link)
This is a breaking change. Previous code may depends on the long include chain.
You may need to include the following headers for some files after this commit:
- soc/soc.h
- soc/soc_memory_layout.h
- driver/gpio.h
- esp_sleep.h
The major broken include chain includes:
1. esp_system.h no longer includes esp_sleep.h. The latter includes driver/gpio.h and driver/touch_pad.h.
2. ets_sys.h no longer includes soc/soc.h
3. freertos/portmacro.h no longer includes soc/soc_memory_layout.h
some peripheral headers no longer includes their hw related headers, e.g. rom/gpio.h no longer includes soc/gpio_pins.h and soc/gpio_reg.h
BREAKING CHANGE
This prevents a device from being bricked in case when both secure boot & flash encryption are enabled and encryption gets interrupted during first boot. After interruption, all partitions on the device need to be reflashed (including the bootloader).
List of changes:
* Secure boot key generation and bootloader digest generation logic, implemented inside function esp_secure_boot_permanently_enable(), has been pulled out into new API esp_secure_boot_generate_digest(). The enabling of R/W protection of secure boot key on EFUSE still happens inside esp_secure_boot_permanently_enable()
* Now esp_secure_boot_permanently_enable() is called only after flash encryption process completes
* esp_secure_boot_generate_digest() is called before flash encryption process starts
1. separate rom include files and linkscript to esp_rom
2. modefiy "include rom/xxx.h" to "include esp32/rom/xxx.h"
3. Forward compatible
4. update mqtt
In the situation when bootloader was compiled for 240MHz, and app was
compiled for 160MHz, and the chip is a revision 0 chip, the
bootloader will assume that the application has also been running at
240MHz. This will cause the chip to lock up later. Modify this to use
a run time check of DPORT_CPUPERIOD_SEL, which indicates which of the
PLL frequencies was used.
Closes https://github.com/espressif/esp-idf/issues/2731.
Added:
* set a secure version in app/bootloader.
* description anti-rollback to ota part
* emulate the secure_version write and read operations
* efuse_em partition.
* a description about a rollback for native_ota_example.
Closes: TW26335
Bootloader used to calculate the number of cache pages assuming that
load address was aligned, while in reality load address for DROM and
IROM was offset by 0x20 bytes from the start of 64kB page. This
caused the bootloader to map one less page if the size of the image
was 0x4..0x1c less than a multiple of 64kB.
Reported in https://esp32.com/viewtopic.php?f=13&t=6952.
