fix: Verify Secure Boot signature before marking OTA successful#294
Open
ambaragrawal33 wants to merge 1 commit intoBlockstream:masterfrom
Open
fix: Verify Secure Boot signature before marking OTA successful#294ambaragrawal33 wants to merge 1 commit intoBlockstream:masterfrom
ambaragrawal33 wants to merge 1 commit intoBlockstream:masterfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR fixes a UX issue where the OTA update process reports "Upgrade successful!" when a user attempts to flash an unsigned firmware binary (e.g., a beta or DIY build) onto production hardware, only for the bootloader to silently reject it and roll back upon reboot.
The Problem
Currently,
ota_user_validateandesp_ota_endverify the file hash and basic structure, but they do not explicitly check the Secure Boot signature block during the USB OTA process. If an unsigned.binis uploaded to a unit withCONFIG_SECURE_BOOT=y, the UI claims success, but the hardware's bootloader rejects the missing signature on the next boot, causing a silent fallback to the previous slot. This leads to user confusion.The Solution
In
main/process/ota_util.c, this PR introduces a call toesp_image_verify()withinota_finalize(just beforeesp_ota_set_boot_partition()is called).If
CONFIG_SECURE_BOOTis enabled, this ensures the written partition is fully validated—including the presence of a valid Secure Boot signature—before the UI reports success. If the signature is missing, it immediately throws an "Invalid Firmware" error to the user, preventing the silent rollback loop.