change(secure_boot): mark ECDSA based Secure Boot V2 as insecure on affected SoCs

ECDSA based Secure Boot V2 is not functional for certain input vectors on
ESP32-C5/C61/H2/P4 and on the preview targets ESP32-H4/H21. RSA based Secure
Boot V2 is the recommended scheme where the SoC supports it. This issue will be
fixed in a future hardware ECO revision; more details will be shared through the
hardware errata document.

A new hidden Kconfig option SECURE_BOOT_V2_ECDSA_INSECURE marks the affected
mass-production SoCs (ESP32-C5/C61/H2/P4). On these SoCs, when hardware Secure
Boot V2 is enabled, the ECDSA (V2) signing scheme is no longer offered by
default; it must be turned on explicitly via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
under "Allow potentially insecure options" (CONFIG_SECURE_BOOT_INSECURE). App
signing without hardware Secure Boot is not affected. Note that ESP32-C61 has no
RSA based Secure Boot V2, so it has no Secure Boot scheme enabled by default.

The preview targets ESP32-H4 and ESP32-H21 mark ECDSA Secure Boot V2 as not
supported in their SoC capabilities instead of using the option above. As
ESP32-H4 has no other Secure Boot V2 scheme, Secure Boot is disabled entirely on
it; ESP32-H21 retains RSA based Secure Boot V2.

The security documentation keeps the ECDSA Secure Boot V2 content visible and
adds a warning describing the limitation (including that ECDSA Secure Boot V2 on
ESP32-C61 is not recommended for production). CI apps that exercise ECDSA Secure
Boot V2 on the affected SoCs set CONFIG_SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
accordingly.

components/bootloader/Kconfig.projbuild

@@ -534,6 +534,18 @@ menu "Security features"
         default y
         depends on SOC_SECURE_BOOT_V2_ECC
 
+    # ECDSA based Secure Boot V2 is not functional for certain input vectors on these
+    # SoCs. The scheme stays available but, for hardware Secure Boot, must be explicitly
+    # turned on via SECURE_BOOT_V2_FORCE_ENABLE_ECDSA under "Allow potentially insecure
+    # options" (CONFIG_SECURE_BOOT_INSECURE).
+    #
+    # TODO: IDF-15721 - drop a SoC from this list once a fixing hardware ECO revision
+    # ships, gating on the selected minimum chip revision, e.g.:
+    #     default y if IDF_TARGET_ESP32C5 && ESP32C5_REV_MIN_FULL < <fixed_rev>
+    config SECURE_BOOT_V2_ECDSA_INSECURE
+        bool
+        default y if IDF_TARGET_ESP32H2 || IDF_TARGET_ESP32P4
+
     config SECURE_BOOT_V1_SUPPORTED
         bool
         default y
@@ -604,6 +616,10 @@ menu "Security features"
         config SECURE_SIGNED_APPS_ECDSA_V2_SCHEME
             bool "ECDSA (V2)"
             depends on SECURE_BOOT_V2_ECC_SUPPORTED && (SECURE_SIGNED_APPS_NO_SECURE_BOOT || SECURE_BOOT_V2_ENABLED)
+            # On the affected SoCs (SECURE_BOOT_V2_ECDSA_INSECURE), hardware Secure Boot with ECDSA
+            # is offered only when SECURE_BOOT_V2_FORCE_ENABLE_ECDSA is explicitly set. App signing
+            # without hardware Secure Boot is not affected by this gate.
+            depends on !SECURE_BOOT_V2_ENABLED || (!SECURE_BOOT_V2_ECDSA_INSECURE || SECURE_BOOT_V2_FORCE_ENABLE_ECDSA)
             help
                 For Secure boot V2 (e.g., ESP32-C2 SoC), appends ECDSA based signature block to the application.
                 Refer to documentation before enabling.
@@ -962,6 +978,19 @@ menu "Security features"
         # it's possible for the insecure menu to be disabled but the insecure option
         # to remain on which is very bad.)
 
+        config SECURE_BOOT_V2_FORCE_ENABLE_ECDSA
+            bool "Force enable ECDSA based Secure Boot V2"
+            depends on SECURE_BOOT_INSECURE && SECURE_BOOT_V2_ECDSA_INSECURE
+            default n
+            help
+                ECDSA based Secure Boot V2 is not functional for certain input vectors on this SoC
+                and is therefore not offered by default. Refer to the hardware errata document for
+                details.
+
+                Setting this option re-enables the ECDSA based Secure Boot V2 signing scheme despite
+                the known vulnerability. Only set this option if you fully understand the risk. RSA
+                based Secure Boot V2 is the recommended scheme on SoCs that support it.
+
         config SECURE_BOOT_ALLOW_ROM_BASIC
             bool "Leave ROM BASIC Interpreter available on reset"
             depends on (SECURE_BOOT_INSECURE || SECURE_FLASH_ENCRYPTION_MODE_DEVELOPMENT) && IDF_TARGET_ESP32