flash.sh: backup rom first, revert to backup if flashing fails for whatever reasons#1870
flash.sh: backup rom first, revert to backup if flashing fails for whatever reasons#1870tlaurion wants to merge 1 commit intolinuxboot:masterfrom
Conversation
…revert to rollback if flashing fails for whatever reason. Warn sleeps and give output. Removed recovery shell access after warning again that we are in known good state (TPMTOTP/HOTP will succeed on next reboot. TODO: remove some output as part of subsequent QUIET cleanup Signed-off-by: Thierry Laurion <insurgo@riseup.net>
1cda403 to
eee1d53
Compare
|
Then the question is: should we skip flash verify operation (time costly) since in case we fail erase or write op, the failsafe implemented here would flash back previously known good firmware (and it's currently known good flash tool) ? |
|
@i-c-o-n hinted using --flash-contents /tmp/${CONFIG_BOARD}_bak.rom to the first write, check it out |
|
Better approach was done under dasharo @i-c-o-n : unless there is a use case I'm not thinking off, there is no need to backup and revert to backup in case of failing if protected range are not attempted to be written to see Dasharo/flashrom#17 |
I guess it depends on the possible state of the flash chip that you want to consider. For instance, on modern Intel systems it's not possible to query the exact state of the flash chip. If you only consider expected states, e.g. what coreboot would configure, then it's fine ofc. But if a user would configure some unexpected protection with an external programmer, things could go wrong again. Same for worn flash chips that don't allow an erase of an individual block anymore. So expect the expected or expect the unexpected? 😆 Looks interesting. In particular the second commit ("Fail immediately...") is close to what I had in mind. I always wanted to gather all the information in a single layout list, then check for conflicting overlaps and bail out early. |
This is WiP for flash.sh to take a backup to be able to rollback into in case anything prevent a successful flash of a new firmware, flashing back the rollback in case of a failed flash, leaving things as they were and successfully passing remote attestation as if no upgrade happened.
Next steps?