Merge branch 'feature/secure_bootv2_c3_v4.3' into 'release/v4.3'

secure_boot_v2: Support SB_V2 for ESP32-C3 ECO3 (v4.3)

See merge request espressif/esp-idf!13062

components/bootloader/Kconfig.projbuild

@@ -471,7 +471,7 @@ menu "Security features"
     config SECURE_BOOT
         bool "Enable hardware Secure Boot in bootloader (READ DOCS FIRST)"
         default n
-        depends on !IDF_TARGET_ESP32C3 # IDF-2647
+        depends on IDF_TARGET_ESP32 || IDF_TARGET_ESP32S2 || ESP32C3_REV_MIN_3
         help
             Build a bootloader which enables Secure Boot on first boot.
 
@@ -488,7 +488,7 @@ menu "Security features"
         help
             Select the Secure Boot Version. Depends on the Chip Revision.
             Secure Boot V2 is the new RSA based secure boot scheme.
-            Supported in ESP32-ECO3. (ESP32 Chip Revision 3 onwards)
+            Supported in ESP32-ECO3 (ESP32 Chip Revision 3 onwards), ESP32-S2, ESP32-C3 ECO3.
             Secure Boot V1 is the AES based secure boot scheme.
             Supported in ESP32 and ESP32-ECO3.
 

components/esp32c3/Kconfig

@@ -25,7 +25,7 @@ menu "ESP32C3-Specific"
 
     choice ESP32C3_REV_MIN
         prompt "Minimum Supported ESP32-C3 Revision"
-        default ESP32C3_REV_MIN_0
+        default ESP32C3_REV_MIN_3
         help
             Minimum revision that ESP-IDF would support.
 

docs/en/api-guides/index.rst

@@ -31,7 +31,7 @@ API Guides
     :esp32: RF Calibration <RF_calibration>
     :esp32: ROM debug console <romconsole>
     :esp32: Secure Boot <../security/secure-boot-v1>
-    :not esp32c3: Secure Boot V2 <../security/secure-boot-v2>
+    Secure Boot V2 <../security/secure-boot-v2>
     Thread Local Storage <thread-local-storage>
     Tools <tools/index>
     :SOC_ULP_SUPPORTED: ULP Coprocessor <ulp>

docs/en/security/flash-encryption.rst

@@ -478,8 +478,7 @@ When using Flash Encryption in production:
    - Do not reuse the same flash encryption key between multiple devices. This means that an attacker who copies encrypted data from one device cannot transfer it to a second device.
    :esp32: - When using ESP32 V3, if the UART ROM Download Mode is not needed for a production device then it should be disabled to provide an extra level of protection. Do this by calling :cpp:func:`esp_efuse_disable_rom_download_mode` during application startup. Alternatively, configure the project :ref:`CONFIG_ESP32_REV_MIN` level to 3 (targeting ESP32 V3 only) and select the :ref:`CONFIG_SECURE_UART_ROM_DL_MODE` to "Permanently disable ROM Download Mode (recommended)". The ability to disable ROM Download Mode is not available on earlier ESP32 versions.
    :not esp32: - The UART ROM Download Mode should be disabled entirely if it is not needed, or permanently set to "Secure Download Mode" otherwise. Secure Download Mode permanently limits the available commands to basic flash read and write only. The default behaviour is to set Secure Download Mode on first boot in Release mode. To disable Download Mode entirely select select the :ref:`CONFIG_SECURE_UART_ROM_DL_MODE` to "Permanently disable ROM Download Mode (recommended)" or call :cpp:func:`esp_efuse_disable_rom_download_mode` at runtime.
-   :not esp32c3: - Enable :doc:`Secure Boot <secure-boot-v2>` as an extra layer of protection, and to prevent an attacker from selectively corrupting any part of the flash before boot.
-   :esp32c3: - Enable Secure Boot (not supported yet) as an extra layer of protection, and to prevent an attacker from selectively corrupting any part of the flash before boot.
+   - Enable :doc:`Secure Boot <secure-boot-v2>` as an extra layer of protection, and to prevent an attacker from selectively corrupting any part of the flash before boot.
 
 Possible Failures
 -----------------
@@ -753,8 +752,7 @@ Flash encryption protects firmware against unauthorised readout and modification
     - Not all data is stored encrypted. If storing data on flash, check if the method you are using (library, API, etc.) supports flash encryption.
     - Flash encryption does not prevent an attacker from understanding the high-level layout of the flash. This is because the same AES key is used for every pair of adjacent 16 byte AES blocks. When these adjacent 16 byte blocks contain identical content (such as empty or padding areas), these blocks will encrypt to produce matching pairs of encrypted blocks. This may allow an attacker to make high-level comparisons between encrypted devices (i.e. to tell if two devices are probably running the same firmware version).
     :esp32: - For the same reason, an attacker can always tell when a pair of adjacent 16 byte blocks (32 byte aligned) contain two identical 16 byte sequences. Keep this in mind if storing sensitive data on the flash, design your flash storage so this doesn't happen (using a counter byte or some other non-identical value every 16 bytes is sufficient). :ref:`NVS Encryption <nvs_encryption>` deals with this and is suitable for many uses.
-    :not esp32c3: - Flash encryption alone may not prevent an attacker from modifying the firmware of the device. To prevent unauthorised firmware from running on the device, use flash encryption in combination with :doc:`Secure Boot <secure-boot-v2>`.
-    :esp32c3: - Flash encryption alone may not prevent an attacker from modifying the firmware of the device. To prevent unauthorised firmware from running on the device, use flash encryption in combination with Secure Boot (not supported yet).
+    - Flash encryption alone may not prevent an attacker from modifying the firmware of the device. To prevent unauthorised firmware from running on the device, use flash encryption in combination with :doc:`Secure Boot <secure-boot-v2>`.
 
 .. _flash-encryption-and-secure-boot:
 

docs/en/security/secure-boot-v2.rst

@@ -5,7 +5,7 @@ Secure Boot V2
 
 .. important::
 
-    The references in this document are related to Secure Boot V2, the preferred scheme from ESP32-ECO3 onwards and in ESP32-S2.
+    The references in this document are related to Secure Boot V2, the preferred scheme from ESP32 ECO3 onwards, in ESP32-S2, and from ESP32-C3 ECO3 onwards.
 
     .. only:: esp32
 
@@ -13,11 +13,20 @@ Secure Boot V2
 
     Secure Boot V2 uses RSA based app and bootloader verification. This document can also be referred for signing apps with the RSA scheme without signing the bootloader.
 
+
+.. only:: esp32
+
+    ``Secure Boot V2`` and RSA scheme (``App Signing Scheme``) options are available for ESP32 from ECO3 onwards. To get these options visible in the menuconfig set :ref:`CONFIG_ESP32_REV_MIN` greater than or equal to `Rev 3`.
+
+.. only:: esp32c3
+
+    ``Secure Boot V2`` is available for ESP32-C3 from ECO3 onwards. To get these options visible in the menuconfig set :ref:`CONFIG_ESP32C3_REV_MIN` greater than or equal to `Rev 3`.
+
 Background
 ----------
 
 Secure Boot protects a device from running unsigned code (verification at time of load). A new RSA based secure boot
-verification scheme (Secure Boot V2) has been introduced for ESP32-S2 and ESP32 ECO3 onwards.
+verification scheme (Secure Boot V2) has been introduced for ESP32-S2, ESP32-C3 ECO3 onwards, and ESP32 ECO3 onwards.
 
 - The software bootloader’s RSA-PSS signature is verified by the Mask ROM and it is executed post successful verification.
 - The verified software bootloader verifies the RSA-PSS signature of the application image before it is executed.
@@ -31,7 +40,7 @@ Advantages
 
     - Only one public key can be generated and stored in ESP32 ECO3 during manufacturing.
 
-  .. only:: esp32s2
+  .. only:: esp32s2 or esp32c3
 
     - Up to three public keys can be generated and stored in the chip during manufacturing.
 
@@ -108,7 +117,7 @@ A signature block is “valid” if the first byte is 0xe7 and a valid CRC32 is
 
     Only one signature block can be appended to the bootloader or application image in ESP32 ECO3.
 
-  .. only:: esp32s2
+  .. only:: esp32s2 or esp32c3
 
     Upto 3 signature blocks can be appended to the bootloader or application image in {IDF_TARGET_NAME}.
 
@@ -145,7 +154,7 @@ eFuse usage
 
     - BLK2 - Stores the SHA-256 digest of the public key. SHA-256 hash of public key modulus, exponent, precalculated R & M’ values (represented as 776 bytes – offsets 36 to 812 - as per the :ref:`signature-block-format`) is written to an eFuse key block.
 
-.. only:: esp32s2
+.. only:: esp32s2 or esp32c3
 
     - SECURE_BOOT_EN - Enables secure boot protection on boot.
 
@@ -171,7 +180,7 @@ How To Enable Secure Boot V2
     3. Specify the secure boot signing key path. The file can be anywhere on your system. A relative path will be evaluated from the project directory. The file does not need to exist yet.
     4. Select the UART ROM download mode in "Security features -> UART ROM download mode". By default the UART ROM download mode has been kept enabled in order to prevent permanently disabling it in the development phase, this option is a potentially insecure option. It is recommended to disable the UART download mode for better security.
 
-.. only:: esp32s2
+.. only:: esp32s2 or esp32c3
 
     2. The "Secure Boot V2" option will be selected and the "App Signing Scheme" would be set to RSA by default.
 
@@ -254,7 +263,7 @@ Secure Boot Best Practices
 * Enable all secure boot options in the Secure Boot Configuration. These include flash encryption, disabling of JTAG, disabling BASIC ROM interpeter, and disabling the UART bootloader encrypted flash access.
 * Use secure boot in combination with :doc:`flash encryption<flash-encryption>` to prevent local readout of the flash contents.
 
-.. only:: esp32s2
+.. only:: esp32s2 or esp32c3
 
     Key Management
     --------------

docs/sphinx-known-warnings.txt

@@ -77,5 +77,3 @@ wear-levelling.rst:line: WARNING: Duplicate declaration, bool esp_vfs_fat_mount_
 wear-levelling.rst:line: WARNING: Duplicate declaration, int esp_vfs_fat_mount_config_t::max_files
 wear-levelling.rst:line: WARNING: Duplicate declaration, size_t esp_vfs_fat_mount_config_t::allocation_unit_size
 wear-levelling.rst:line: WARNING: Duplicate declaration, esp_vfs_fat_mount_config_t
-bootloader.rst:line: WARNING: undefined label: config_secure_boot (if the link has no caption the label must precede a section header)
-secure-boot-v2.rst:line: WARNING: undefined label: config_secure_boot_insecure (if the link has no caption the label must precede a section header)

tools/unit-test-app/sdkconfig.defaults.esp32c3

@@ -1 +1,3 @@
 CONFIG_ESP_SYSTEM_MEMPROT_FEATURE=n
+CONFIG_ESP32C3_REV_MIN_0=y
+CONFIG_ESP32C3_REV_MIN=0