Preserve hardened firmware verification result
What changed, and why it matters
This bootloader patch changes how the result of a security check on the currently-running firmware is stored. Previously, the code immediately converted the secure verification result into a plain true/false boolean. Now it keeps the special secure result value intact and compares it directly later. This is a hardening fix: it reduces the chance that a subtle type-conversion bug or compiler optimization could let a failed firmware check be treated as a pass, which in turn could allow a malicious or corrupted firmware update to proceed.
Review the broader bootloader update.c logic to ensure all security results use secresult consistently, verify that verify_current_firmware() cannot return values other than SEC_TRUE/SEC_FALSE that would now behave differently, and confirm the change is covered by firmware update tests. No immediate user action is indicated beyond applying the firmware update containing this fix.
Security signals we found
Hardened firmware verification result preservation
Replacement of bool with secresult for security-critical return value
Bootloader update path depends on firmware validity check
Defensive coding against type-conversion/optimization risks
Evidence from the diff
In update_firmware(), the old code stored the return value of verify_current_firmware(true) in a bool after comparing it to SEC_TRUE. The patch stores the raw secresult enum value and performs the SEC_TRUE comparison at each use site. This preserves the hardened verification status through the update flow and avoids collapsing a multi-valued security result into a boolean early. The functional behavior appears equivalent, but the change is defensive: it prevents the secure result from being silently altered by implicit conversions, future edits, or compiler optimizations, and keeps the security-critical value in a secresult-typed variable.
Changed components
ports/stm32/boards/Passport/bootloader/update.cupdate_firmware()verify_current_firmware() result handlingInspect captured patch +5 / −5
diff --git a/ports/stm32/boards/Passport/bootloader/update.c b/ports/stm32/boards/Passport/bootloader/update.c
index 5e0913f..d229bcf 100644
--- a/ports/stm32/boards/Passport/bootloader/update.c
+++ b/ports/stm32/boards/Passport/bootloader/update.c
@@ -338,8 +338,8 @@ void update_firmware(void) {
}
}
- bool is_spi_fw_user_signed = spihdr.signature.pubkey1 == FW_USER_KEY;
- bool is_current_firmware_valid = false;
+ bool is_spi_fw_user_signed = spihdr.signature.pubkey1 == FW_USER_KEY;
+ secresult current_firmware_result;
// Handle the firmware hash update
get_current_board_hash(current_board_hash);
@@ -356,8 +356,8 @@ void update_firmware(void) {
#ifdef DEBUG_PRINT_UPDATE_HASH
printf("Verifying current firmware before update\r\n");
#endif
- is_current_firmware_valid = verify_current_firmware(true) == SEC_TRUE;
- if (is_current_firmware_valid) {
+ current_firmware_result = verify_current_firmware(true);
+ if (current_firmware_result == SEC_TRUE) {
#ifdef DEBUG_PRINT_UPDATE_HASH
printf(" Current firmware is valid, so doing more checks.\r\n");
#endif
@@ -424,7 +424,7 @@ void update_firmware(void) {
}
}
- if (is_current_firmware_valid) {
+ if (current_firmware_result == SEC_TRUE) {
/*
* Calculate a new board hash based on the SPI firmware and then
* reprogram the board hash in the SE. If the update fails it
Why this scored 57/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.