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

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

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? 😆

see Dasharo/flashrom#17

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.