alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2025-09-30 19:19:21 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'docs/update_USB-OTG_ESP32S2_ESP32S3' into 'master'

Browse Source 
updated USB_OTG in dfu.rst, usb_device.rst and secure-boot-v2.rst

Closes DOC-3565

See merge request espressif/esp-idf!20144
This commit is contained in:
Zhang Xiao Yan
2022-12-27 14:38:51 +08:00
parent b043c55f0a 9c0d573eae
commit ae639f68a6
4 changed files with 9 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
docs/en/security/secure-boot-v2.rst
View File

@@ -72,7 +72,7 @@ Secure Boot V2 Process
This is an overview of the Secure Boot V2 Process. Instructions how to enable Secure Boot are supplied in section :ref:`secure-boot-v2-howto`.
Secure Boot V2 verifies the bootloader image and application binary images using a dedicated *signature block*. Each image has a separately generated signature block which is appended to the end of the image.
Secure Boot V2 verifies the bootloader image and application binary images using a dedicated *signature block*. Each image has a separately generated signature block which is appended to the end of the image.
.. only:: esp32
@@ -86,13 +86,13 @@ Secure Boot V2 verifies the bootloader image and application binary images using
Up to 3 signature blocks can be appended to the bootloader or application image in {IDF_TARGET_NAME}.
Each signature block contains a signature of the preceding image as well as the corresponding {IDF_TARGET_SBV2_KEY} public key. For more details about the format, refer to :ref:`signature-block-format`. A digest of the {IDF_TARGET_SBV2_KEY} public key is stored in the eFuse.
Each signature block contains a signature of the preceding image as well as the corresponding {IDF_TARGET_SBV2_KEY} public key. For more details about the format, refer to :ref:`signature-block-format`. A digest of the {IDF_TARGET_SBV2_KEY} public key is stored in the eFuse.
The application image is not only verified on every boot but also on each over the air (OTA) update. If the currently selected OTA app image cannot be verified, the bootloader will fall back and look for another correctly signed application image.
The Secure Boot V2 process follows these steps:
1. On startup, the ROM code checks the Secure Boot V2 bit in the eFuse. If Secure Boot is disabled, a normal boot will be executed. If Secure Boot is enabled, the boot will proceed according to the following steps.
1. On startup, the ROM code checks the Secure Boot V2 bit in the eFuse. If Secure Boot is disabled, a normal boot will be executed. If Secure Boot is enabled, the boot will proceed according to the following steps.
2. The ROM code verifies the bootloader's signature block (:ref:`verify_signature-block`). If this fails, the boot process will be aborted.
@@ -322,6 +322,8 @@ Restrictions after Secure Boot is enabled
- After Secure Boot is enabled, no further eFuses can be read protected. (If :doc:`/security/flash-encryption` is enabled then the bootloader will ensure that any flash encryption key generated on first boot will already be read protected.) If :ref:`CONFIG_SECURE_BOOT_INSECURE` is enabled then this behavior can be disabled, but this is not recommended.
- Please note that enabling Secure Boot or flash encryption disables the USB-OTG USB stack in the ROM, disallowing updates via the serial emulation or Device Firmware Update (DFU) on that port.
.. _secure-boot-v2-generate-key:
Generating Secure Boot Signing Key