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.
ESP32 V1 and V2 - protection bits.
ESP32xx V2: revoke bits, protection bits
- refactor efuse component
- adds some APIs for esp32 chips as well as for esp32xx chips
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
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).
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
Allows OTA updates to be secured via signature checks, without requiring the overhead or complexity
of a full secure boot implementation.
Uses same signing mechanisms (build system and/or espsecure.py as Secure Boot).
Requires:
* [ ] More testing
* [ ] Documentation
Makes app image booting more reliable (256-bit rather than 8-bit verification.)
Some measurements, time to boot a 655KB app.bin file and run to app_main() execution.
(All for rev 1 silicon, ie no 340ms spurious WDT delay.)
80MHz QIO mode:
before = 300ms
after = 140ms
40MHz DIO mode:
before = 712ms
after = 577ms
40MHz DIO mode, secure boot enabled
before = 1380ms
after = 934ms
(Secure boot involves two ECC signature verifications (partition table, app) that take approx 300ms each with 80MHz CPU.)
* App access functions are all flash encryption-aware
* Documentation for flash encryption
* Partition read/write is flash aware
* New encrypted write function
Shu Chen