From 5cdd3999c73411aa00ec319b43e5c93ba1875414 Mon Sep 17 00:00:00 2001
From: Mahavir Jain <mahavir@espressif.com>
Date: Tue, 7 Dec 2021 09:47:05 +0530
Subject: [PATCH 1/2] bootloader_support: fix Coverity scan warning

Null pointer dereferences  (REVERSE_INULL) :

Null-checking "part" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
---
 .../bootloader_support/src/esp_image_format.c | 20 ++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/components/bootloader_support/src/esp_image_format.c b/components/bootloader_support/src/esp_image_format.c
index 803a8879d3..ebfd92c9c8 100644
--- a/components/bootloader_support/src/esp_image_format.c
+++ b/components/bootloader_support/src/esp_image_format.c
@@ -127,25 +127,27 @@ static esp_err_t image_load(esp_image_load_mode_t mode, const esp_partition_pos_
     uint32_t checksum_word = ESP_ROM_CHECKSUM_INITIAL;
     uint32_t *checksum = (do_verify) ? &checksum_word : NULL;
     bootloader_sha256_handle_t sha_handle = NULL;
+    bool verify_sha;
 #if (SECURE_BOOT_CHECK_SIGNATURE == 1)
      /* used for anti-FI checks */
     uint8_t image_digest[HASH_LEN] = { [ 0 ... 31] = 0xEE };
     uint8_t verified_digest[HASH_LEN] = { [ 0 ... 31 ] = 0x01 };
 #endif
-#if CONFIG_SECURE_BOOT_V2_ENABLED
-    // For Secure Boot V2, we do verify signature on bootloader which includes the SHA calculation.
-    bool verify_sha = do_verify;
-#else // Secure boot not enabled
-    // For secure boot V1 on ESP32, we don't calculate SHA or verify signature on bootloaders.
-    // (For non-secure boot, we don't verify any SHA-256 hash appended to the bootloader because
-    // esptool.py may have rewritten the header - rely on esptool.py having verified the bootloader at flashing time, instead.)
-    bool verify_sha = (part->offset != ESP_BOOTLOADER_OFFSET) && do_verify;
-#endif
 
     if (data == NULL || part == NULL) {
         return ESP_ERR_INVALID_ARG;
     }
 
+#if CONFIG_SECURE_BOOT_V2_ENABLED
+    // For Secure Boot V2, we do verify signature on bootloader which includes the SHA calculation.
+    verify_sha = do_verify;
+#else // Secure boot not enabled
+    // For secure boot V1 on ESP32, we don't calculate SHA or verify signature on bootloaders.
+    // (For non-secure boot, we don't verify any SHA-256 hash appended to the bootloader because
+    // esptool.py may have rewritten the header - rely on esptool.py having verified the bootloader at flashing time, instead.)
+    verify_sha = (part->offset != ESP_BOOTLOADER_OFFSET) && do_verify;
+#endif
+
     if (part->size > SIXTEEN_MB) {
         err = ESP_ERR_INVALID_ARG;
         FAIL_LOAD("partition size 0x%x invalid, larger than 16MB", part->size);

From 1501a22e023675c923cc222247b6ee561e0e6d6a Mon Sep 17 00:00:00 2001
From: Mahavir Jain <mahavir@espressif.com>
Date: Tue, 7 Dec 2021 09:49:28 +0530
Subject: [PATCH 2/2] docs: fix salt length in secure-boot-v2 docs

---
 docs/en/security/secure-boot-v2.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/en/security/secure-boot-v2.rst b/docs/en/security/secure-boot-v2.rst
index ef34fea7b0..2242105da6 100644
--- a/docs/en/security/secure-boot-v2.rst
+++ b/docs/en/security/secure-boot-v2.rst
@@ -132,7 +132,7 @@ The content of each signature block is shown in the following table:
       - Pre-calculated M’, derived from ‘n’
     * - 812
       - 384 
-      - RSA-PSS Signature result (section 8.1.1 of RFC8017) of image content, computed using following PSS parameters: SHA256 hash, MFG1 function, 0 length salt, default trailer field (0xBC).
+      - RSA-PSS Signature result (section 8.1.1 of RFC8017) of image content, computed using following PSS parameters: SHA256 hash, MFG1 function, salt length 32 bytes, default trailer field (0xBC).
     * - 1196
       - 4 
       - CRC32 of the preceding 1095 bytes.