safely flash bootloader firmware to both slots #26
Conversation
This file contains 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
Information from Daniel Micay <danielmicay@gmail.com>: SoC firmware anti-rollback protection is being actively used for 6th and 7th generation Pixels. The code implementing this was deployed as part of Android 13 resulting in an initial rollback version increase. Consider the situation where a device shipped with v5 firmware and was upgraded to v7 by the user. It has v7 on the current slot and v5 on the alternate slot. It has been successfully booted with v7 firmware so the OS has incremented the rollback version to v7. If the user unlocks and unsuccessfully flashes new firmware or a new OS, the device rolls back to the other slot, bricking itself. The safest solution to this problem is flashing the unused slot with the new firmware, making it active, booting it and then repeating it. This makes sure that the new firmware is flashed to both slots and verifies that it boots up successfully before proceeding with flashing the OS. It makes sense to do this for ALL devices because all devices can deploy similar anti-rollback protection and this also improves overall safety of installation. Anti-rollback protection isn't the only reason that the inactive slot could have non-booting firmware. Something could have gone wrong previously so the user only has 1 booting firmware slot remaining. This new approach makes fastboot.js much safer than Google's approach to flashing. GrapheneOS has adopted this for both fastboot.js and also the CLI flashing script in the factory images zip since shortly after the release of Android 13. It's very well tested now and we've avoided the issues with bricked devices people are experiencing with flashing the stock OS.
|
Flashing to both slots makes sense, but why reboot in between?
If something went wrong and it doesn't boot up successfully, the device could get bricked now rather than later. If nothing went wrong, it'll boot fine either way, so I don't see how this part improves safety or reliability. Am I missing something? |
|
If the newly flashed firmware fails to boot, the device will switch back to the other slot. It only gets bricked when there's invalid firmware flashed to both slots. Only flashing the firmware to the inactive slot is safer and largely prevents bricking the device this way. There are still edge cases but it deals with the major things that could go wrong. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Information from Daniel Micay danielmicay@gmail.com:
SoC firmware anti-rollback protection is being actively used for 6th and 7th generation Pixels. The code implementing this was deployed as part of Android 13 resulting in an initial rollback version increase.
Consider the situation where a device shipped with v5 firmware and was upgraded to v7 by the user. It has v7 on the current slot and v5 on the alternate slot. It has been successfully booted with v7 firmware so the OS has incremented the rollback version to v7. If the user unlocks and unsuccessfully flashes new firmware or a new OS, the device rolls back to the other slot, bricking itself.
The safest solution to this problem is flashing the unused slot with the new firmware, making it active, booting it and then repeating it. This makes sure that the new firmware is flashed to both slots and verifies that it boots up successfully before proceeding with flashing the OS.
It makes sense to do this for ALL devices because all devices can deploy similar anti-rollback protection and this also improves overall safety of installation. Anti-rollback protection isn't the only reason that the inactive slot could have non-booting firmware. Something could have gone wrong previously so the user only has 1 booting firmware slot remaining. This new approach makes fastboot.js much safer than Google's approach to flashing.
GrapheneOS has adopted this for both fastboot.js and also the CLI flashing script in the factory images zip since shortly after the release of Android 13. It's very well tested now and we've avoided the issues with bricked devices people are experiencing with flashing the stock OS.